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

[Michael StJohns <[e-mail]>]

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.  That 
applies regardless of which hash we select.   That said, SHA256 is 
probably a better choice that SHA1 given that SHA1 is deprecated for 
signatures [while this isn't exactly using it in signatures, I will note 
that  ECDSA (SHA256(SHA1(data)) has the same strength as 
ECDSA(SHA1(data)) - I would have to think a bit whether the addition of 
the 4 possibly fixed (or chosen) elements would increase the security 
back to SHA256 levels]

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.

Lastly, if we do the above, please add a uint32 length(transcript) value 
before handshake_hash(transcript) to at least make extension attacks a 
bit more difficult.



Mike


>
>
>
>     -Ilari
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls