Re: [TLS] TLS renegotiation issue

[Bodo Moeller <[e-mail]>]

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.