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

Watson Ladd <watsonbladd@gmail.com> Sat, 27 December 2014 16:58 UTC

Return-Path: <watsonbladd@gmail.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 B16051A8971 for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 08:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 BerRjXZWkZId for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 08:58:54 -0800 (PST)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2BB1A896B for <tls@ietf.org>; Sat, 27 Dec 2014 08:58:53 -0800 (PST)
Received: by mail-yh0-f41.google.com with SMTP id a41so5736809yho.28 for <tls@ietf.org>; Sat, 27 Dec 2014 08:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zVNSl4t/WuOaftfKxIrpoFPPYoyI0bKP7VseOmq26sk=; b=qqKPIxEeUzv10LJjdocMfgRxteej8PAtNl99EDqQNAkZDzHtWEaeniPImhlAoiEZ9Y +jIb5ejLEg4BiCaJ63QQOldlzuajsI7V2kc9U+yyxDwTKG/VcG5KZsYOUGTycTMw7Xyo kmpJPwEeOlCcYckHU1GcLTYIad6nDG8igAY23e0n+DMOYdpnfGWRp6NbmqYEpH81EdkA piebKuxh69/Ldlxp4FQENcYA1wAR0X9eRYuLOTpDUoXN06bLDutU7qjZvcVGZp8aXdlx AaMNG3NPqRfBp5K66WZbijk1lHDhZ833G8vOa2HhHA6w4s2NrKDLbZyGFObrz4P6DM8t J1hA==
MIME-Version: 1.0
X-Received: by 10.236.53.69 with SMTP id f45mr34705747yhc.65.1419699532957; Sat, 27 Dec 2014 08:58:52 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Sat, 27 Dec 2014 08:58:52 -0800 (PST)
Received: by 10.170.207.6 with HTTP; Sat, 27 Dec 2014 08:58:52 -0800 (PST)
In-Reply-To: <549EE32B.7050703@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>
Date: Sat, 27 Dec 2014 11:58:52 -0500
Message-ID: <CACsn0ckmdiTUVD5QVH+hpN4OLJk=OWCc_1PvCzsEGhzNpkQ4HQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=089e0122971c598d66050b358e6d
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NZxAmp_SROG86eu6qMg5rB2tBJs
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." <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 16:58:57 -0000

On Dec 27, 2014 11:50 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.  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.

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

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

>
>
>
> Mike
>
>
>
>>
>>>
>>>
>>>
>>>
>>> -Ilari
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>