For those following along, that might not know about PFS, what exactly does it enable or unlock? Do some other protocols require it?

I found http://en.wikipedia.org/wiki/Forward_secrecy

Is this specific to network encryption implementations?

Added Area-Library, Library-IO, Triaged labels.

Could you please explain what it is that is needed for PFS in dart:io. As far as I can see you get FPS when using TLS to suecure the connection. Or am I missing something?

Added NeedsInfo label.

This comment was originally written by @Emasoft

@sgjesse: Developers are having difficulties implementing secure web applications. For instance according to Luiz Mineo, developer of Redstone.dart, (I quote) "HSTS can only be implemented resorting to an interceptor (i.e. a cpp wrapper of an instance of a native peer C/C++ object) or using shelf middleware", while "there is no support for PFS on Dart at all". This is a serious shortcoming for a web development platform like Dart.

Perfect Forward Secrecy (PFS) (aka Ephemeral Keys Exchange) should satisfies the 3 properties below:

• The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.
• Generates random public keys per session for the purposes of key agreement.
• Does not use any sort of deterministic algorithm in doing so.
• Must renegotiate DH parameters each session. Ephemeral Diffie Hellman is used for PFS. Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes. So "each session" quite literally means as soon as the session ends the keys are destroyed. No session IDs are stored by the server, so new keys are forced each time.
  Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys. So new DH parameters are needed with *DHE cipher suites. Some servers might have to disable session resumption to ensure this occurs. This is explicitly defined in RFC5246 TLS 1.2 Standard: "Implementations SHOULD generate a new X for each handshake when using DHE cipher suites."
• The Ephemeral cipher suites should be at the top of the preferred list. For example:

var (
    // The ECDHE cipher suites are preferred for performance and forward
    // secrecy. See https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy.
    preferredCipherSuites = []uint16{
        tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
        tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
        tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA,
        tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
        tls.TLS_RSA_WITH_RC4_128_SHA,
        tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA,
        tls.TLS_RSA_WITH_AES_128_CBC_SHA,
        tls.TLS_RSA_WITH_AES_256_CBC_SHA,
        tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
        tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    }
)

Currently Dart doesn't allow to do that.

Here are a couple of posts made by Adam Langley, Senior Staff Software Engineer at Google:

https://www.imperialviolet.org/2011/11/22/forwardsecret.html
https://www.imperialviolet.org/2013/12/03/forwardsecretforjournalists.html

You can ask him how to implement PFS in the Dart framework.

So the feature request is to configure the preferred TLS cipher suites to a set that will adheres to the Perfect Forward Security properties? Maybe even have this be the default.

This comment was originally written by @Emasoft

I think the problem is more complex than just changing the preferred TLS cipher suites and putting the Ephemeral ones first. Dart is not able to satisfie the 3 properties listed above.

This comment was originally written by luiz.mine...@gmail.com

"@sgjesse: Developers are having difficulties implementing secure web applications. For instance according to Luiz Mineo, developer of Redstone.dart, (I quote) "HSTS can only be implemented resorting to an interceptor (i.e. a cpp wrapper of an instance of a native peer C/C++ object) or using shelf middleware", while "there is no support for PFS on Dart at all". This is a serious shortcoming for a web development platform like Dart."

Well, that's definitely not exactly what I said... Let me paste here my comment on the Google+ thread (https://plus.google.com/u/0/112869608698337579825/posts/AyNJZAhSqGW):

"HSTS can be easily implemented with an interceptor or shelf middleware, although, I think there is no support for PFS on Dart yet."

With "interceptor", I meant an Redstone interceptor (http://redstonedart.org/doc/Interceptors.html). You just have to add a new header to your response for enabling HSTS.

And with "I think there is no support for PFS on Dart yet", I meant that I'm not sure if this specification can be implemented in Dart, but I didn't tried it myself.

I got the following answer from Adam Langley:

"""
Just supporting the ciphersuites will generally be enough to make
people happy but you're correct that doing it right involves getting
session ticket key distribution correct. See
https://www.imperialviolet.org/2013/06/27/botchingpfs.html and
https://blog.twitter.com/2013/forward-secrecy-at-twitter. The key
distribution isn't really an SSL library matter, it's higher-level
than that.
"""

Those two blog posts explains PFS this quite precisely. The explanation of how Twitter implemented the session ticket key distribution shows what is needed for a server farm for providing PFS together with session resumption.

Right now there is no API in dart:io to do anything with the session ticket key.

Added Triaged label.