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

From: Adam Langley <[email-masked]>
Date: Mon, 1 Dec 2014 14:28:28 -0800

On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla <[email-masked]> wrote:
> If someone wants to contribute a PR so that we can have something
> concrete to look at that would be even better.

I have submitted a PR for the padding and context-string changes:
https://github.com/tlswg/tls13-spec/pull/100

I did not change the CertificateVerify structure in the same commit
because I'm not quite sure that I follow the reasoning. The
CertificateVerify implicitly contains the client and server nonce
because it contains all the preceding handshake messages. What's the
motivation for duplicating them at the beginning? Is it simply to
avoid having the opaque signer understand the TLS structure? If so,
does the padding and context strings that I've just proposed break
that?

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 02 Dec 2014 09:29:29 +0100

> does the padding and context strings that I've just proposed break

Is this about the comment in
https://www.ietf.org/mail-archive/web/tls/current/msg14764.html ?
If yes, it is unrelated to the context issue. By having an explicit
server random value, a server can delegate the TLS protocol to a worker
process, while he can still verify that the connected peer is the
intended. For that, the server only needs to explicitly set the
server_random data and then verify the client's CertificateVerify
message based on that. That would allow  designs with privilege
separation (e.g., similar to openssh's) to use TLS. Without the explicit
random values, the server would have to receive the whole TLS transcript
and calculate the hash over it.

In short it allows the server or the client to provide a short proof
that they established a session with a particular peer.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Dec 2014 13:38:36 -0800

Adam updated his PR to sign the prefix concatenated with the handshake
hashes, which makes it easier to have a single hash context.

I haven't seen any objections to this idea, so I'll merge this on Wednesday
unless I hear an objection before then.

-Ekr

P.S. I note that this doesn't address
Nikos's issue (
https://www.ietf.org/mail-archive/web/tls/current/msg14764.html)
but that seems separable, and I'd encourage those who think that's a good
idea to weigh in on a different thread.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Dec 2014 16:37:19 +0200

> unless I hear an objection before then.

Any reason not to fix the hash function per-ciphersuite, so servers
and clients don't have to run multiple hashes in parrallel? 

Suitable hash function is required by the THS fix anyway, and one
could just reuse that context if one has implementation capable of
intermediate hashes or hash context cloning.

If one is worried about cross-hash attacks (even if all hashes should
be strong), stick the ciphersuite ID (which fixes the hash) into
data to be signed.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 10:21:58 -0800

> and clients don't have to run multiple hashes in parrallel?

The client and server may want to use different signature algorithms.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Dec 2014 20:50:31 +0200

> The client and server may want to use different signature algorithms.

I mean the hash in data to be signed (not the internal hash function in
signature algortithm).

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)

Where handshake_hash is the same hash as used by session hash (that one
better be CR anyway!)

This PR lacks the domain separation and requires both sides to buffer
handshake or run potentailly lots of hashes (instead of just running
one they need to run anyway).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 10:55:53 -0800

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

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Dec 2014 21:39:06 +0200

> a signature with (say) SHA-1 over a handshake hash computed with

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

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 13:01:45 -0800

> 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

---

From: Adam Langley <[email-masked]>
Date: Sat, 27 Dec 2014 16:32:01 +0100

> Thanks for the clarification. What do other people think about this

I think it's a great idea. I'll send a PR after the holiday unless
someone beats me to it.

Cheers

AGL

---

From: Michael StJohns <[email-masked]>
Date: Sat, 27 Dec 2014 11:49:47 -0500

> Thanks for the clarification. What do other people think about this 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Sat, 27 Dec 2014 11:58:52 -0500

suggestion?
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]

I think you are misreading. A certificate may use SHA1 as a supported
signing algorithm, while SHA256 is the PRF. In short the order got flipped
around, or I misread AGL's proposal/example.

The reason for this proposal is a known weakness in TLS 1.2 that narrowly
escaped being a vulnerability.

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.

This doesn't make any sense. We're talking about signatures, not PRF MAC.
Length extension doesn't matter.

---

From: Adam Langley <[email-masked]>
Date: Sat, 27 Dec 2014 18:01:32 +0100

On Sat, Dec 27, 2014 at 5:49 PM, Michael StJohns <[email-masked]> wrote:
> Doing it this way means that SHA1 is a permanent part of TLS1.3

The signature hash is negotiated, not fixed to SHA-1. TLS 1.2 (and,
currently, 1.3) depend on SHA-256 fundamentally as it's the weakest
handshake hash allowed.

> at least make extension attacks a bit more difficult.

Length extension attacks allow hashes of some other input messages to
be calculated. Since the input to the signature hashes is already
public, that's not a problem.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Dec 2014 09:01:15 -0800

On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <[email-masked]>
wrote:

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

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

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Sat, 27 Dec 2014 12:41:23 -0500

On 12/27/2014 12:01 PM, Eric Rescorla wrote:
>
>
> On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     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.
>
>
> - In the current draft, you sign transcript using whatever 
> signature/hash pair

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Dec 2014 10:06:24 -0800

On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <[email-masked]>
wrote:

> 1) Client offers a number of cipher suites, with the result that there are
> multiple hash functions (PRF) possible.
> 3) Server knows which hash function the client is using so it can use the
> same one?  Assuming it implements that.
>
>
> 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.

> 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

---

From: Michael StJohns <[email-masked]>
Date: Sat, 27 Dec 2014 15:34:15 -0500

On 12/27/2014 1:06 PM, Eric Rescorla wrote:
>
>
> On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns 
>>>         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.
>>
>>
>     1) Client offers a number of cipher suites, with the result that
>     there are multiple hash functions (PRF) possible.
>     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
> 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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Dec 2014 13:10:10 -0800

> 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
> both sides negotiate to TLS1.3 (because of limiting suites to AEAD suites),
> but RFC 6367  has (section 3.3b):
>
Ah, good point. Thanks.

-Ekr

>>> still need to run multiple hashes in parallel until it gets the tls version
>> 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
> for the session_hash computation, so Ilari's proposal will often reduce
> the number of

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Dec 2014 09:02:47 -0800

I've updated AGL's PR as described above.

https://github.com/tlswg/tls13-spec/pull/110

I'll be merging this later today. Please comment on the PR if I introduced
any errors.

-Ekr