Re: [TLS] TLS renegotiation issue

[Bodo Moeller <bmoeller at acm.org>]

On Nov 5, 2009, at 10:16 AM, Eric Rescorla wrote:

> I now have a draft extension up at:
>
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml

[= http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt]


There's pointless overhead in the following extract: Sending the  
client's verify_data to the server for verification makes sense;  
sending the server's verify_data to the client for verification makes  
less sense, but still sense; sending another copy of the client's  
verify_data to the client, however, doesn't make sense.  Using  
symmetric 12-byte values, where each party sends its own previous  
verify_data, achieves the same with fewer bytes.

Bodo


            struct {
               opaque renegotiated_connection<0..255>;
             } Renegotiation_Info;

   All TLS implementations SHOULD support this extension.  TLS clients
   SHOULD generate it with every handshake and TLS servers SHOULD
   generate it in response to any client which offers it.

   The contents of this extension are specified as follows.

   o  If this is the initial handshake for a connection, then this  
field
      is of zero length in both the ClientHello and the ServerHello.
   o  For ClientHellos which are renegotiating, this field contains the
      verify_data from the Finished message sent by the client on the
      immediately previous handshake.  For current versions of TLS,  
this
      will be a 12-byte value.  Note that this value is the "tls- 
unique"
      channel binding from [I-D.altman-tls-channel-bindings]
   o  For ServerHellos which are renegotiating, this field contains the
      concatenation of the verify_data values sent by the client and  
the
      server (in that order) on the immediately previous handshake.   
For
      current versions of TLS, this will be a 24-byte value.