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

[Michael StJohns <[e-mail]>]

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.

So the way to get around the above is to: pick a set of handshake 
algorithms that everyone has to implement and make them fixed. Which led 
me to the "everyone has to implement SHA1" based on the prior email.

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

Mike




>
> -Ekr
>