- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 9 Oct 2014 09:43:12 -0700
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Greg Wilkins <gregw@intalio.com>, Eric Rescorla <ekr@rtfm.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 9 October 2014 03:36, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > Why did you assume that PFS is the same as DHE/ECDHE key exchange? That's not > true even in current TLS. I think that's just a common misconception about the (EC)DHE key exchange. That is, that they offer PFS (they can, but don't necessarily), and that they are the only options. The current text in 9.2.2 is very careful on this point. > How does this handle version skew (and "surprise" ciphers), both at client and > server? One can get ciphersuites that are UNKNOWN if those are 9.2.2-compliant > (without TLS introspection APIs, that one presumably can't assume present). Surprise ciphers might trigger the behaviour Greg is recommending. That's why we recommend that you don't offer ciphers you don't understand, and don't select them. Obviously, this might still happen with some combinations of implementations. > Disabling any ciphers as response to TLS handshake abort (which is > completely unauthenticated[2]!) is a VERY bad idea (the proposal does not > say to do it, but neither it says to not do it)[3]. This is not what is being recommended. What is being recommended is disabling h2 in response to an inability to negotiate h2. That's far less of a problem.
Received on Thursday, 9 October 2014 16:43:40 UTC