Re: [TLS] What would be the point of removing signalling in TLS 1.3? [correction]

[David-Sarah Hopwood <[e-mail]>]

David-Sarah Hopwood wrote:
> Bodo Moeller wrote:
>> On Nov 26, 2009, at 10:22 PM, Marsh Ray wrote:
>>> Stefan Santesson wrote:
>>>> If you fix the Finished message calculation, making it immune to the
>>>> renegotiation attack, and making it the standard Finished calculation
>>>> for
>>>> 1.3.... Then why would you need to signal that you are using the
>>>> standard
>>>> Finished calculation?
>>> So that clients and servers can be upgraded over a period of time
>>> without causing interoperability problems.
>> There are more than two ways how to treat signaling (how to signal that
>> a new Finished computation should be used) with respect to future
>> protocol versions, i.e., TLS 1.3 and later:
> 
> [numbering added]
>> 1. The specifications could mandate keeping the explicit signal even with
>> TLS 1.3+.
>>
>> 2. The specifications could require an explicit signal only for those TLS
>> 1.3+ implementations that do offer backwards compatibility with earlier
>> protocol versions (i.e., if the *negotiated* protocol version is TLS 1.3
>> or later, that would imply that the new Finished computation should be
>> used).
>>
>> 3. The specifications could require an explicit signal only for
>> implementations that don't announce TLS 1.3+ (i.e., if the *requested*
>> protocol version is TLS 1.3+, that would imply that the new Finished
>> computation should be used).
>>
>> Stefan's proposal in the original message, it seems, was the third
>> variant.  David's comment suggested that because of the complexity that
>> comes with that variant, we should stick to the first one (and always
>> keep signaling).
>>
>> That's not implied, though.  The second variant makes a lot of sense to
>> me -- it's just not something that the current specification would or
>> should have to say a final word on: that's best left to the TLS 1.3
>> specification.
> 
> No, we have to decide now. For approach 2 to work, *every* patched
> implementation must know that requesting TLS 1.3+ implies that a
> client is patched. For approach 3 to work, *every* patched implementation
> must know that negotiating TLS 1.3+ implies that a server is patched.

Correction:
For approach 3 to work, *every* patched implementation must know that
requesting TLS 1.3+ implies that a client is patched.

> If we leave it until TLS 1.3 is specified, then there will exist
> implementations that don't know these things. Therefore, TLS 1.3+ clients
> will have to send the c->s signal anyway, in case the server is one of
> those that doesn't know that a TLS 1.3+ request implies that it is OK to
> send the s->c signal. Similarly, TLS 1.3+ servers will have to send
> the s->c signal anyway, in case the client is one of those that doesn't
> know that negotiating TLS 1.3+ implies being patched.

The second part of this is wrong: TLS 1.3+ can be negotiated only
if the client supports it, therefore it can be assumed that the client
knows that negotiating TLS 1.3+ implies being patched.

However, the first part was correct. So, "not deciding" is effectively
equivalent to deciding against approach 3 (and also against a combination
of 2 and 3), while still leaving the choice between 1 and 2 open.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com