On 08/08/18 15:01, Benjamin Kaduk 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...
Well, it is an error condition. The client is expecting this to be ok and it isn't and has to abruptly close. close_notify doesn't seem like a good match to me. Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
