On Wed, Mar 30, 2016 at 12:29 PM Subodh Iyengar <sub...@fb.com> wrote:
> >I disagree with point #3 and think the "prevent fallback" portion would > be a mistake. Possession of a TLS 1.3 session to offer should not disable > TLS 1.2 if the client would have accepted this without that session. > > @David, for #3, I'm referring to fallback in 0-RTT mode. In the normal > operation case I don't think fallbacks work at all in this mode, so it > should be fine to reject it to prevent attacks like I mentioned below. > > For example let's say a client sends a 0-RTT packet and the server only > supports TLS1.2, the server will return a server hello with TLS1.2. However > when it reads data from the session buffer expecting a ClientKeyExchange > message, it will start getting the 0-RTT data. > Oh, I see. Yeah, that TLS 1.3 is backwards incompatible here is unfortunate, for the same heterogeneous-deployment reasons as session resumption. As things stand, enabling 0-RTT on one machine in a fleet is a promise that *all* machines have deployed TLS 1.3 and that TLS 1.3 will *never* be rolled back (unless turn off 0-RTT on all machines and then wait for things to expire first, but typically one needs to roll something back because it is broken and needs attention). Deployments that just ship pre-packaged server software will not get this right. TLS 1.3 should not require TLS experts guiding deployment. (I understand that this backwards incompatibility is necessary for TLS 1.3 clients to stream 0-RTT data. I think this is a mistake for TLS over TCP (though it is, of course, fine for other profiles like QUIC or DTLS), but I've probably lost that one.) > In a case where the server is smart enough to discard all this data (maybe > its a special TLS1.2 + TLS1.3 server), the behavior when this happens on > the client side is unspecified, should the client supply the data again in > the normal TLS stream? should it not resend that data? > If the server responds with a != TLS 1.3 ServerHello with an indication that it accepted the early data then, agreed, that should be a fatal error. This is for the same reasons as forbidding cross-version session resumption. If the server responds with a < TLS 1.3 ServerHello and *doesn't* indicate early data, that's a different question. If the client does accept it, the client should supply the data again, as it would have with TLS 1.3. But, actually, I think I may buy this too should be a fatal error, but not for security reasons. I think trying to use this as version downgrade protection in so narrow of a scope does not make sense. Rather, because TLS 1.3 0-RTT is currently backwards-incompatible, TLS 1.3 forces a connection retry fallback[0]. Clients offering 0-RTT need to retry without 0-RTT enabled[1]. Using "server sent a < TLS 1.3 ServerHello to a ClientHello with 0-RTT data" as a fallback trigger is at least a reliable one. If we must have a fallback (I would rather we didn't), it shouldn't be a flaky one. David [0] We seem to have several meanings of the word "fallback" here. :-) One to mean where we accept a ServerHello at lower version than the ClientHello, and another to mean when you start a connection over from the top with different parameters, akin to the insecure TLS version fallback browsers do/did. I'm referring to the second one. [1] Without lowering the ClientHello version, of course. Though TLS 1.3 intolerance, sadly, seems to exist, so that might also happen again independently. > It's probably better to reject this fallback when the client has chosen to > explicitly use a TLS 1.3 feature with 0-RTT in general. > > Subodh > ________________________________________ > From: Martin Thomson [martin.thom...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM > To: David Benjamin > Cc: Subodh Iyengar; tls@ietf.org > Subject: Re: [TLS] Tickets and cross protocol attacks > > On 30 March 2016 at 05:00, David Benjamin <david...@chromium.org> wrote: > > On the server, OpenSSL already includes the version in the SSL_SESSION > > structure, and recent enough versions of it will not accept sessions at > the > > wrong version > > > NSS too. This is the right thing, I think. > > I have no objection to making this a requirement in the spec. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
