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