The spec is actually extremely clear on this point https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below MUST check that the last 8 bytes are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last 8 bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an "illegal_parameter" alert. I think it's way late to change it. -Ekr On Wed, Aug 8, 2018 at 7:01 AM, Benjamin Kaduk <bka...@akamai.com> wrote: > On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote: > > > > > > On 08/08/18 14:45, Eric Rescorla wrote: > > > > > > > > > On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell <m...@openssl.org > > > <mailto:m...@openssl.org>> wrote: > > > > > > > > > > > > On 08/08/18 14:21, Benjamin Kaduk wrote: > > > > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote: > > > >> Draft 28 defines the inappropriate_fallback alert as follows: > > > >> > > > >> inappropriate_fallback Sent by a server in response to an > invalid > > > >> connection retry attempt from a client > > > >> > > > >> With the introduction of the downgrade protection sentinels it > now seems > > > >> that an inappropriate fallback could also be detected by the > client. > > > >> Should this wording be changed? > > > > > > > > Well, *fallback* specifically is inherently client-driven; the > things the > > > > client could detect would be more of an incorrectly negotiated > version > > > > (presumably due to an active attack). > > > > > > Consider the scenario where a server supports TLSv1.3/TLSv1.2 but > does > > > not support RFC7507 (TLS Fallback Signalling Cipher Suite Value). > > > > > > If the client attempts a TLSv1.3 connection first and fails (e.g. > an > > > active attacker prevented it) and then falls back to TLSv1.2 it > would be > > > able to detect that its fallback attempt was inappropriate when it > sees > > > the downgrade protection sentinels. In that case > inappropriate_fallback > > > seems reasonable. > > > > > > > > > I don't think that is the alert I would choose in this circumstance. > > > Probably "illegal_parameter" > > > > illegal_parameter suggests to me that the peer is misbehaving in some > > way - which isn't the case here? Also it seems strange that we would > > have a more explicit alert than the generic illegal_parameter, that > > seems to precisely describe the scenario (a fallback occurred, and it > > turns out it was inappropriate) but not be able to use it. > > Aren't the semantics here "whoops, I made a new connection attempt that > I shouldn't have; let me go back out of that"? In which case one could > argue even for close_notify... > > -Ben >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
