Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Thu, 17 Feb 2011 11:54:35 +0100, Eric Rescorla <[e-mail]> wrote:

> On Thu, Feb 17, 2011 at 11:49 AM, Nikos Mavrogiannopoulos
> <[e-mail]> wrote:
>> On Thu, Feb 17, 2011 at 10:35 AM, Eric Rescorla <[e-mail]> wrote:
>>
>>>>> I see the potential problem.  For me, though, I just hold onto all
>>>>> of the handshake messages until the handshake concludes.  It may use
>>>>> a bit more memory for a short amount of time, but the issue you raise
>>>>> is completely avoided.  Call it a space <-> code complexity
>>>>> trade-off.
>>>> Indeed. There is no other way to correctly implement TLS 1.2 except
>>>> from holding a copy of all the handshake messages. This is problematic
>>>> when converting an implementation of TLS 1.0 or 1.1 to that, since
>>>> those protocols only required to hold the state of 1 or 2 running  
>>>> hashes.
>>> Is that really true?. My memory from the discussions and briefly
>>> refreshed by looking at the
>>> doc is that you only need to hold the messages until you see the
>>> ServerHello at which point
>>> you know the PRF and so you can just start storing hashes.
>>
>> Note that you're talking about the hashes required for the finished
>> messages and you're correct on this note. However there is also the
>> hash required for the CertificateVerify message. If the server requests
>> a client certificate then it has to store all messages up to (but not
>> including) the CertificateVerify message.
>> That is because he cannot possibly know which signature algorithm
>> hash the client will use.
>
> Agreed. I can't recall if we discussed this when this feature was being  
> designed
> for 5246 but ISTM that the only way to have this work that didn't have
> this property would be for the client to offer all his certificates
> up-front and the
> server to select one, since it's possible that each cert comes with a  
> specific
> hash algorithm tied to it.

How about removing the need to calculated the verify message based on a  
specific hash of the handshake message?

Currently the verify message is defined as


       struct {
            digitally-signed struct {
                opaque handshake_messages[handshake_messages_length];
            }
       } CertificateVerify;

How about changing that to this?


       struct {
            digitally-signed struct {
                 PRF(master_secret, verify_label, Hash(handshake_messages))
                           [0..f(Cert_Hash)-1];
            }
       } CertificateVerify;


This would remove the need to store all the handshake messages, or manage  
multiple hashes of the same data, since the handshake-hash would take care  
of that.

Using the PRF means that we can generate a string that is of sufficient  
length for each method, although an alternative if one think that is too  
complex, or generally unnecessary, is to just use Hash(handshake_messages).

A possible issue is how this would affect security if the Cert_Hash method  
is much more secure than the Hash method. My current opinion is that this  
can be handled by using f(Cert_Hash) to provide a sufficiently long PRF,  
unless there are issues I am unaware of with such a solution. I'll leave  
that to the members for experienced in cracking crypto constructs.

Of course, making this change requires a new TLS protocol version.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************