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

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

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.

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.

Thus, "not deciding" is effectively equivalent to deciding on approach 1.

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