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

[Michael StJohns <[e-mail]>]

On 12/27/2014 1:06 PM, Eric Rescorla wrote:
>
>
> On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns 
> <[e-mail] <mailto:[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] <mailto:[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.


>
> 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.



>
>
>
>>         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
>