Re: [TLS] Redefine Finished message for TLS 1.3 ?

[Bodo Moeller <[e-mail]>]

On Nov 14, 2009, at 11:13 AM, Nelson B Bolyard wrote:
> On 2009-11-13 08:46 PDT, Nicolas Williams wrote:

>>
>> The post with message-ID <[e-mail]>, subject
>> "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600
>> yesterday most certainly described no Hello extensions, only a  
>> Finished
>> message verify_data computation change.
>
> EKR and Marsh Ray and some others will recall that I proposed  
> essentially
> the same proposal that Nico is now proposing in the meeting meeting in
> Mountain View on September 29, 2009 to which Marsh Ray invited EKR,  
> myself
> and numerous others from this working group.
>
> I proposed that a change in the computation of the TLS Finished  
> message
> to include some value derived from the master secret previously in  
> use on
> the connection before the current renegotiation (such as the Finished
> message contents or some other value "extracted" from the master  
> secret)
> would avoid the overhead of the new extensions on the wire.  My goal  
> was
> to avoid the extra bandwidth and memory cost of those extensions,  
> which
> might be deemed too costly in certain low memory or bandwidth  
> constrained
> applications.
>
> Others in the meeting responded that changing the definition of the
> computation of the Finished messages was a change to the base protocol
> specification (which adding an extension is not), and thus the change
> I proposed would make TLS become (say) TLS 1.3.

In that proposal, would there have been any explicit indicator sent by  
the client and server to indicate that they intend to use the the  
modified Finished message?


One way to avoid most of the overhead from the current ID would be to  
keep the extension *always* empty.  If the client and server both send  
it during any given handshake, then the Finished messages concluding  
that handshake will be computed mostly in the standard way, but if  
it's a renegotiation handshake, including the previous handshake's  
Finished messages in the handshake_messages that will be hashed.   
[Open question: Where should they go?  Maybe the easiest is to always  
hash them at the end; client first, server second.]

This has the same security properties as  draft-rescorla-tls- 
renegotiation-00.txt, but saves 40 plaintext bytes (or 28 over the  
obvious variant of that ID where you remove the non-functional  
overhead, i.e. the server's copy of the client's verify_data.)

The step up to TLS 1.3 will be easy: Just make the modified Finished  
computation the default for the new protocol (i.e., no longer  
requiring the extension-based negotiation).

Bodo