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 A042B1A9060 for ; Sat, 27 Dec 2014 09:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 uAJAV1W0GIsc for ; Sat, 27 Dec 2014 09:01:57 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2431A8F51 for ; Sat, 27 Dec 2014 09:01:56 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so16021766wgg.25 for ; Sat, 27 Dec 2014 09:01:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CtL5BTHjUnIMpY4jvLvfVfo+5myHyCKiMjabE48QScs=; b=GHkH+i+TD8gHiUZOy3UOYhhDOX8ZYIkv9p07GCxsBuGibNlJB3n+1bfXFfaT8tn5ky uBGIktjuS3etYkn/KulEn+gA5kotbmKMks5BcCCaEXDoQBjkxliJUSkBwl5UUzhlh/kt 2fK2AdQiqI2/cLyyjSOburcmdfaiGXDHGAPymsIsjipAN3azTFPzEiQ9MiVfNXwK8Mti h9x02YU8QBc7ZS4CpW2VKpbG4QAQ898gOTMFU/hG5/qyKM9itCruZTOc0cpUzBd7Y09p RNuFzXzj0P+YWYq6Px2kXztp3jNkHJ1GBie0/9EE58N63/NYbW2U+dfgBA9BLm++yBdJ fU8A== X-Gm-Message-State: ALoCoQlKyxJcFQOm9VHPmDslh3k5aXsLm9haG7gmtsESC8Xs3+6AmwapTQeZEESlz4EC0RkpFopY X-Received: by 10.180.85.33 with SMTP id e1mr77808358wiz.61.1419699715598; Sat, 27 Dec 2014 09:01:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 27 Dec 2014 09:01:15 -0800 (PST) In-Reply-To: <549EE32B.7050703@nthpermutation.com> 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> From: Eric Rescorla Date: Sat, 27 Dec 2014 09:01:15 -0800 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d044280743c81f3050b359963 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hJAGn3qgJfvIGEvx2DTsAC-kR3M 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 17:01:59 -0000 --f46d044280743c81f3050b359963 Content-Type: text/plain; charset=UTF-8 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()). > 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. -Ekr --f46d044280743c81f3050b359963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
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.=C2=A0 It also means that the securit= y 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.=C2=A0

I don't believ= e that this is correct.

- In the current draft, yo= u sign transcript using whatever signature/hash pair
=C2=A0 you h= ave selected. Call that hash H1. So, you sign H1(transcript).
- In AGL's existing PR, you sign H1(context || H1(transcrip= t))

- In Ilari's proposal, you sign H1(con= text || H2(transcript)) where H2 is
=C2=A0 that Hash used by the = PRF, which is SHA-256 for the current cipher
=C2=A0 suites.
=

So, in the case where you want to sign with RSA-SHA1, y= ou would in the
first case just sign with SHA1, in the second do = SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA25= 6()).


=C2=A0
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.=C2=A0

Yes. This = is at least in principle also true with TLS 1.3 if we were to define
<= div>(and the client were to support) a PRF based on some other hash, such
as SHA-512.

-Ekr

--f46d044280743c81f3050b359963--