On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <hka...@redhat.com> wrote:
> In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > As I mentioned a while back, we've been seeing evidence of middlebox > > intolerance. I just posted PR 1091, which is based on a bunch of work > > by the BoringSSL team and an original suggestion by Kyle Nekritz that > > should significantly decrease the rate of these errors. > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > resumption. The major changes are: > > > > - Move version negotiation entirely into "supported_versions", and hence > > ServerHello.version == 0x0303 (TLS 1.2) > > - Restore the missing session_id and compression fields in ServerHello > > less special cases in parser code - big +1 > > > - The client sends a fake session_id and the server echoes it > > - The server sends ChangeCipherSpec messages after > > ServerHello/HelloRetryRequest > > (so that the middlebox ignores any "encrypted" data afterwards), > > and the client sends ChangeCipherSpec after ClientHello. Either > > side has to ignore ChangeCipherSpec during the handshake. > > That's the part I have a bit of a problem with. > If the CCS is necessary to make middleboxes work, and given that > lack-of-CCS- > intolerance is not something that we can detect reliably (not in a way that > can be simulated by an attacker), I think the CCS should be baked in the > TLS > 1.3 as deep as it was baked into TLS 1.2. > You don't detect it on an individualized basis. Rather, you measure whether it's necessary and if/when the necessary level of CCS becomes low enough, you just stop sending it ever. That is, the standard should make it a mandatory message to send, fully > parsed > and validated, requiring aborting connection if it is received at any > unexpected moment, in duplicate, omitted or malformed. Not only as part of > the > "compatibility mode". > Yeah, I'm not enthusiastic about this. It's more stuff in the state machine that we hope to eventually eliminate. And as David says, it's totally unnecessary for QUIC and DTLS -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
