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

[Eric Rescorla <[e-mail]>]

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.

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.



 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