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. Matt > > -Ekr > > > Matt > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
