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

Eric Rescorla <ekr@rtfm.com> Sat, 27 December 2014 21:10 UTC

Return-Path: <ekr@rtfm.com>
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 F06991A923E for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 13:10:56 -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 oxLitBCC6oTm for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 13:10:53 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89881A90B3 for <tls@ietf.org>; Sat, 27 Dec 2014 13:10:52 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id l15so19207925wiw.8 for <tls@ietf.org>; Sat, 27 Dec 2014 13:10:51 -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=dcCaNEF4tqsi0YAqhLlZIKZKZlvk6a/kv1LfMcagx44=; b=PxdMH3uWGLrJBPqpYwB/P8ZAM+7zdHi0LVgcLmQhUEVHeMKrUYkw86mNX9sXFdqmcv iS+psMDXCHybKiwZsLggX1CpjMfiIP+w93Uw1BTjSnxHQfiwDgIb5em5+FFk05861WUC 6HV6g0W2f/3h9K/31wpoo/VLTUc7OwPHxC1Bp2H47DJDe30ZameZ/F7zrpAJ3xTBcpaA gz4Od9UqvphEhYqUvXZZs/5lb8Bv/8NzgCl893aaYhW2qf5XwM5kaobyUq+1iU9sjuU6 jFdUVyu3vhG/HhpfY7xuWsGmpGcpt6k8Cbm+RUEn7TlKocUnsBA2e30GI6fe/ey3wVT+ Hm0g==
X-Gm-Message-State: ALoCoQnPRdmRAR84yL7cqpCrhak+8ZQb9pPX45jQKkXXg5EIZ4Za15xVIfuyzga9uqV201BjeDVE
X-Received: by 10.194.2.105 with SMTP id 9mr95575392wjt.115.1419714651354; Sat, 27 Dec 2014 13:10:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.130.34 with HTTP; Sat, 27 Dec 2014 13:10:10 -0800 (PST)
In-Reply-To: <549F17C7.8090003@nthpermutation.com>
References: <CAMfhd9XgR-N6BZVLojfyf6E2+0fhYVHopp5FKALoup_GjTji5A@mail.gmail.com> <CABcZeBMmFWOoh6Av=eAaMi6AA1Kb7X41Efie-0PuRZWwPPVz_A@mail.gmail.com> <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <CABcZeBPHQGMNYU1QbG=oeuVZYG71BqVaJU9E9e2Kh+rEWq=RXA@mail.gmail.com> <CAL9PXLwrZCgDUqd8ugqhcpYEBwLOcQXSLg8Kx8fgCq6tzLvO4A@mail.gmail.com> <CABcZeBPY8Jrg_ou_=frs9O2-0nrfL+V-H-jBCxDgQ4Ora55kvQ@mail.gmail.com> <20141223143719.GB11149@LK-Perkele-VII> <CABcZeBOb9tL5UO94Qrdn7AuamkPvs=+7aU0EF78p3Lac=JEh9w@mail.gmail.com> <20141224185031.GA4583@LK-Perkele-VII> <CABcZeBO2D+DBW+XAzNv9BgXqXzmy8GgwbX24iGZDYXN=aqZ9fg@mail.gmail.com> <20141224193906.GB4583@LK-Perkele-VII> <CABcZeBOD_6Uan73ntOBKb3JwhYB2xzhrz+xGue_sy-B4-1VA4A@mail.gmail.com> <549EE32B.7050703@nthpermutation.com> <CABcZeBN1_o4Dqv90iK9-z_robXNFsChCe016LU7tBRkjycH4dg@mail.gmail.com> <549EEF43.3020608@nthpermutation.com> <CABcZeBNeH7ZzqPCiGkupgpiZNjPXdVkMuFjbdfaZ5zpa_5Gi2Q@mail.gmail.com> <549F17C7.8090003@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 27 Dec 2014 13:10:10 -0800
Message-ID: <CABcZeBN1jhc0Y7ejc5x7h1ub1daBw2NvLCJHXVMj3dneKem-Qg@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=047d7b3440ee7a0da4050b3913f3
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LLHhHY1bEwB0aGINPlg51FynzBk
Cc: "tls@ietf.org" <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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Dec 2014 21:10:57 -0000

On Sat, Dec 27, 2014 at 12:34 PM, Michael StJohns <msj@nthpermutation.com>;
wrote:

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

Yes, that sounds right.


>
>

>  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 <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.
>
>
Ah, good point. Thanks.

-Ekr


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