Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E348D1A9172 for ; Sat, 27 Dec 2014 12:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeqh-XZ8JH_E for ; Sat, 27 Dec 2014 12:34:12 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B051A9170 for ; Sat, 27 Dec 2014 12:34:11 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id f51so8046410qge.4 for ; Sat, 27 Dec 2014 12:34:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=4+setz/eYCHXqyyoumRZoKsHJo4FpIQRhhaDqLAssUo=; b=gKomtYLrFewto0e61UlWQHqo6lk4+zlT4pn180sjQ1Lhc4piP3oqcZv/+eJtuWelGm 6rwSSF4y5ENei4hfSwPwndYHXLEv2e8HLtSehkwhz9htCpxgp4vy2sa3X0lCmHnMNAGX nVQ6runcSY86M8YzA8+G5G9H1wwn21gZvXPaRpENJrLgU3fQSb+Dq1Xq46sr020eMRhD S9NE2Lr6dw5Kx/aBkoeK+CIIQ/BvnSDVKs/W8OkwKyy68UiPavtDRrj6mEV88AjgjpeT L36URF9T65bn6S+raWmStiZ9jSGa/R9SyutVoNEsZhWbsORppkaUnAN41Yv2jIbEcHSA 0sKQ== X-Gm-Message-State: ALoCoQnMS1FZE3uM4ZQ+EjVpdhqD+sBUgKy06wkVdUVsJQIvT46mSN1fFRAKDCPIaGM3XrR9iCSC X-Received: by 10.224.32.69 with SMTP id b5mr46747121qad.53.1419712450653; Sat, 27 Dec 2014 12:34:10 -0800 (PST) Received: from [192.168.1.105] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id f105sm29350906qge.1.2014.12.27.12.34.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Dec 2014 12:34:10 -0800 (PST) Message-ID: <549F17C7.8090003@nthpermutation.com> Date: Sat, 27 Dec 2014 15:34:15 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eric Rescorla References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> <549EEF43.3020608@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030300080206020408040507" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/av47OEhAO-ECdg_X_rFONrN4h14 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 20:34:15 -0000 This is a multi-part message in MIME format. --------------030300080206020408040507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/27/2014 1:06 PM, Eric Rescorla wrote: > > > On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns > > wrote: > > On 12/27/2014 12:01 PM, Eric Rescorla wrote: >> >> >> On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns >> > 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 ] as the > MAC algorithm. The PRF is the TLS PRF [8 ] with SHA-384 [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 > --------------030300080206020408040507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/27/2014 1:06 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/27/2014 12:01 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <msj@nthpermutation.com> 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] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [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


--------------030300080206020408040507--