- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Thu, 9 Oct 2014 13:36:04 +0300
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Oct 09, 2014 at 05:06:39PM +1100, Greg Wilkins wrote: > Eric, > > Here is a variation of the previous PR: > https://github.com/http2/http2-spec/pull/627 > > I've reverted TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 to a MUST and switched > the connection retry case to only when a client does inadequate security on > a cipher it was offering > for h1 fallback. > > So most connections will be 1 round trip for old and new servers. There > will be 2 round trips IFF a client chooses to offer weak ciphers for h1 > fallback and there is a difference with 9.2.2 interpretation. A client can > avoid having to implement the retry if it chooses to never offer a cipher > that it will not accept for h2. > > Then no matter what the future brings in terms of ciphers, if a client and > server share a cipher/protocol pair then they will be able to connect. > This allows us to be strict in 9.2.2 - with the knowledge that if > circumstances do force deployment of non 9.2.2 compliant ciphers, we do not > risk communication failure. Why did you assume that PFS is the same as DHE/ECDHE key exchange? That's not true even in current TLS. 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). E.g. How does server behave if it gets E413 (???) negotiated somehow, a ciphersuite it has no idea what it is? What about client in comparable situation[1]? 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]. [1] At least those version skew/"surprise" ciphers are unlikely to be weak (might not be the best ciphers around, but should at least be fit for the purpose). [2] Even the certificate can not be trusted to not be forged until handshake completion (not that mismatched ciphersuites even get that far). [3] At least if fallback connect happens with the same TLS version and the same ciphers, the server will probably pick some rather good cipher, and not some bad cipher like RC4. -Ilari
Received on Thursday, 9 October 2014 10:36:30 UTC