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

[Bodo Moeller <[e-mail]>]

On Nov 28, 2009, at 5:24 AM, David-Sarah Hopwood wrote:
> 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.

Yes.  That's exactly what I meant:

The arguments against approach 3 don't imply that we should be using  
approach 1 -- but only the TLS 1.3 specification will really have to  
decide between approach 1 and approach 2.

Bodo