>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. 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? 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
