Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string.

[Eric Rescorla <[e-mail]>]

On Sat, Dec 27, 2014 at 12:34 PM, Michael StJohns <[e-mail]>
wrote:

>  On 12/27/2014 1:06 PM, Eric Rescorla wrote:
>
>
>
> On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <[e-mail]>
> wrote:
>
>>   On 12/27/2014 12:01 PM, Eric Rescorla wrote:
>>
>>
>>
>> On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <[e-mail]>
>> wrote:
>>
>>>  On 12/24/2014 4:01 PM, Eric Rescorla wrote:
>>>
>>>
>>>  > >
>>>> > > That is, it would be digital signature of:
>>>> > >
>>>> > > - 32 padding bytes (or ClientRandom)
>>>> > > - 32 padding bytes (or ServerRandom)
>>>> > > - Context string
>>>> > > - Ciphersuite ID (to provode domain separation)
>>>> > > - handshake_hash(transcript)
>>>> > >
>>>> >
>>>> > So to be clear, you are proposing that we might (for instance) have
>>>> > a signature with (say) SHA-1 over a handshake hash computed with
>>>> > SHA-256?
>>>>
>>>> Yes.
>>>>
>>>> E.g ECDSA/SHA1 for signatures and
>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>> for connection. That would result in SHA-1 signature over SHA-256 hash.
>>>>
>>>>
>>>> The other way around can't happen with any current ciphersuite (because
>>>> every current one has prf-hash of either SHA-256 or SHA-384).
>>>
>>>
>>>  Thanks for the clarification. What do other people think about this
>>> suggestion?
>>>
>>>  -Ekr
>>>
>>>
>>>  Three items -
>>>
>>> Doing it this way means that SHA1 is a permanent part of TLS1.3 - every
>>> implementation will need it.  It also means that the security of the
>>> handshake transcript part is no better than that given by SHA1 so if
>>> further attacks on SHA1 are discovered, the fix will be TLS1.4.
>>>
>>
>>  I don't believe that this is correct.
>>
>>  - In the current draft, you sign transcript using whatever
>> signature/hash pair
>>   you have selected. Call that hash H1. So, you sign H1(transcript).
>>
>>  - In AGL's existing PR, you sign H1(context || H1(transcript))
>>
>>  - In Ilari's proposal, you sign H1(context || H2(transcript)) where H2
>> is
>>   that Hash used by the PRF, which is SHA-256 for the current cipher
>>   suites.
>>
>>  So, in the case where you want to sign with RSA-SHA1, you would in the
>> first case just sign with SHA1, in the second do SHA1(... || SHA1()),
>> and in the third case do SHA1(...., || SHA256()).
>>
>>
>>  I admit to a lot of confusion then as to what you're trying to do here:
>>
>> 1) Client offers a number of cipher suites, with the result that there
>> are multiple hash functions (PRF) possible.
>> 2) Client uses which hash function to summarize the transcript?
>> 3) Server knows which hash function the client is using so it can use the
>> same one?  Assuming it implements that.
>>
>>
>> My point here is that I don't see that you're gaining anything as mostly
>> the client doesn't know what the server knows until after the server tells
>> it.  The clients choice of which hash (or even which handshake signature
>> algorithm) to use will be prone to error until it gets a response from the
>> server confirming it.  I think a client  has to maintain parallel hash
>> contexts for all offered hash functions until the server makes its choice
>> known.
>>
>
>  Yes, that's correct, but it's not the end of the analysis. Consider the
> diagram of
> the handshake from Figure 1:
>
>        ClientHello
>       ClientKeyShare            -------->
>                                                       ServerHello
>                                                    ServerKeyShare
>                                                [ChangeCipherSpec]
>                                              EncryptedExtensions*
>                                                      Certificate*
>                                               CertificateRequest*
>                                                CertificateVerify*
>                                 <--------                Finished
>       [ChangeCipherSpec]
>       Certificate*
>       CertificateVerify*
>       Finished                  -------->
>       Application Data          <------->        Application Data
>
>
>  In the current design, the client does not know which digest algorithm
> the server
> will sign with until the receipt of the CertificateVerify message, so it
> must
> parallel hash the server's entire second flight. Similarly, the server
> does not
> know what the client will select so it must parallel hash its entire second
> flight and the client's Certificate message. By contrast, with the approach
> Ilari suggests, both sides only need to parallel hash up to the
> ServerHello.
>
>
> OK - That makes more sense.  So the TLS1.3 ServerHello contains an
> indication of which hash will be used over the handshake transcript and
> that will be the same as the selected hash function for the PRF etc.
>

Yes, that sounds right.


>
>

>  It's also worth noting that the potential set of algorithms used in the
> PRF is
> currently much narrower than the set of algorithms that implementations
> typically support for signature verification (consisting presently of just
> SHA-256) and so this also reduces the burden on both sides.
>
>
> It might not exactly be applicable to the current discussion assuming
> both sides negotiate to TLS1.3 (because of limiting suites to AEAD suites),
> but RFC 6367  has (section 3.3b):
>
>     b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1 <http://tools.ietf.org/html/rfc6367#ref-1>] as the
>        MAC algorithm.  The PRF is the TLS PRF [8 <http://tools.ietf.org/html/rfc6367#ref-8>] with SHA-384 [13 <http://tools.ietf.org/html/rfc6367#ref-13>] as
>        the hash function.
>
>
Ah, good point. Thanks.

-Ekr


>
>
>
>
>
>      If the client is willing to negotiate to TLS1.2, the client will
>>> still need to run multiple hashes in parallel until it gets the tls version
>>> selection confirmation (and the cipher suite selection) from the server as
>>> we're not changing how the TLS1.2 signature is calculated.
>>>
>>
>>  Yes. This is at least in principle also true with TLS 1.3 if we were to
>> define
>> (and the client were to support) a PRF based on some other hash, such
>> as SHA-512.
>>
>>
>>  Yup - but AFAICT, the only restriction for what goes into the .prf slot
>> in the cipher suite is that it must be a hash function useable with HMAC.
>> I would expect future suites to propose SHA3 based hashes for example as
>> well as regional/national hash functions.  And I would expect those to work
>> without changes to the underlying TLS protocol.
>>
>
>  Yes, that might well happen (though to my knowledge, we have not yet
> standardized any
> regional/national digest functions and I don't see a lot of enthusiasm for
> SHA-3). But
> both sides are already required to handle these cases because that is the
> hash used
> for the session_hash computation, so Ilari's proposal will often reduce
> the number of
> parallel hashes you have to run and will not increase it.
>
>  -Ekr
>
>
>