Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC04B12B069 for ; Mon, 20 Jun 2016 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l90_LSw2OTBl for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEBF12B060 for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f126so69707346wma.1 for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) 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; bh=R4tpwctaSpOADns+NgQdi4g1HKYGfc/Tdz9wiegKL8E=; b=IGRUbWg/5U4bGLjUvagj94oBMRlEe396CxKvUwXDUom105DUhYtqh0pdxv/azuQcoO XES1/Bv8PsLcSJpEfWaF4Q1fnRzo92bOsEI3qjKe4QhCshVeGA5cxWFyP+3k9HuWDb3X P2M9aD8qkm4oHFRcJ4Hztsl33WLgVdBYN0UPfmUCTNCSRYWMbjm6giXIccBjl+f9pvha fbq6KuEI+moykvLnA+5LU1yBF6H5a28dgRuQNO+h9QSRmgsrAgVXVcfGTZNijgDjP0aq 6Q/6ZASHiclqrMA8iRE4VMof3Bo2qRfWIWgxROS1lsbVOtog3Dpqd9bCdlFMjFu7JWSL 3Tfw== 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:date :message-id:subject:from:to:cc; bh=R4tpwctaSpOADns+NgQdi4g1HKYGfc/Tdz9wiegKL8E=; b=S8lKcB9+RD65vkct/tEIn0CiRpl1uqyBZAslFwso5MEfau3ofnDmfpGxJpLo0gtUpJ lLofq7AIl+vKUZ5zdpe1tdX1tSn0GeDwgDb2LxVpCFXgBGngyBLtWVCbnKFJYgsc0TyN C9WNwgf3L+Ale6WISi1XnPJOFe3lvZwKPpRDRPSENvnvUVzrbYfIz2xcJZbQ5StHhEp2 cwfiUVMaO0GighRuVtKcq2ELNdy/KGRSFp8pLm87oPozGodcSueeCKWZleeGSnDz7Cvy o0i+Lq/NdADWnP+JRCneV97uJcyaq7SreC0Y4j6KbJXfOIHjB/CxxB00N3OCrdFqJPo9 UWHQ== X-Gm-Message-State: ALyK8tJuIirQrWESDgx84goixQFX6gPjGzLEBFKhwydiZlzkaRjEEnzZN1K2FgVm9nYEMOeQnjYaLXFayoHWzA== MIME-Version: 1.0 X-Received: by 10.194.201.70 with SMTP id jy6mr16436176wjc.150.1466429633871; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) Received: by 10.28.29.14 with HTTP; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) Received: by 10.28.29.14 with HTTP; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jun 2016 15:33:53 +0200 Message-ID: From: Maarten Bodewes To: David Benjamin Content-Type: multipart/alternative; boundary=047d7b874aba6a463f0535b5c1b1 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 20 Jun 2016 13:33:58 -0000 --047d7b874aba6a463f0535b5c1b1 Content-Type: text/plain; charset=UTF-8 Hi David, Great. Thanks for following up on this! I think I now understand why the implementation of DH seemed buggy in one of the crypto libraries that I was reviewing. Regards, Maarten Op 19 mei 2016 21:22 schreef "David Benjamin" : > If the WG agrees with this change, I've put together a PR here: > https://github.com/tlswg/tls13-spec/pull/462 > > On Tue, May 17, 2016 at 4:14 PM David Benjamin > wrote: > >> Reviving this thread, I also think it would also be a good idea if 1.3 >> did not stripping zeros from Z. Having this logic is rather dubious w.r.t. >> treating secret data in constant-time. And as Bill Cox mentioned >> elsewhere in this thread, this odd behavior has caused interoperability >> issues in the past. >> >> I don't think we have to be worried about inconsistency with 1.2 as, by >> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE >> is already a very different beast from TLS 1.2 DHE. At this point, the only >> thing they meaningfully share is they happen to use the same code points. >> >> David >> >> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley >> wrote: >> >>> I would prefer to always use the full, known-length byte string for Z. >>> In my experience, it is better to know the lengths of byte strings instead >>> of stripping leading zeroes. The difference in the speed of the HKDF >>> computation by omitting the leading zeros is not significant. Alignment >>> with NIST SP 800-56A is nice, but it is not the reason for my preference. >>> >>> Russ >>> >>> >>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes >>> wrote: >>> >>> > Hi all, >>> > >>> > I see that the leading zero is stripped off of the value of Z (the >>> shared secret) before it is used as input to HKDF. This seems to be >>> compatible with TLS 1.2. Then again, it is not compatible with e.g. >>> NISP800-56A which uses the value of Z with the same size of the prime in >>> octets. Furthermore, it is also different with regards to handling the >>> coordinate X as used in ECDH. >>> > >>> > Was this a conscious decision to keep compatibility with TLS? Has the >>> use of the value of Z including zero octets been considered? >>> > >>> > Regards, >>> > Maarten >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> --047d7b874aba6a463f0535b5c1b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi David,

Great. Thanks for following up on this!

I think I now understand why the implementation of DH seemed= buggy in one of the crypto libraries that I was reviewing.

Regards,
Maarten

Op 19 mei 2016 21:22 schreef "David Benjami= n" <davidben@chromium.org<= /a>>:
If the WG agrees with this change, I've put together a PR here:https://github.com/tlswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin &= lt;davidben@chro= mium.org> wrote:
Reviving this thread, I also think it would also be a good idea if 1.= 3 did not stripping zeros from Z. Having this logic is rather dubious w.r.t= . treating secret data in constant-time.=C2=A0And as Bill Cox mentioned elsewhere in this thread, this odd behavior ha= s caused interoperability issues in the past.

I d= on't think we have to be worried about inconsistency with 1.2 as, by th= e time this happens, we will already know we're speaking 1.3. TLS 1.3 D= HE is already a very different beast from TLS 1.2 DHE. At this point, the o= nly thing they meaningfully share is they happen to use the same code point= s.

<= div dir=3D"ltr">
David

On Thu, Apr 7, 2016 at 10:37 AM Russ Housley <housley@vigilsec.com> wrote:
=
I would prefer to always use the full,= known-length byte string for Z.=C2=A0 In my experience, it is better to kn= ow the lengths of byte strings instead of stripping leading zeroes.=C2=A0 T= he difference in the speed of the HKDF computation by omitting the leading = zeros is not significant.=C2=A0 Alignment with NIST SP 800-56A is nice, but= it is not the reason for my preference.

Russ


On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com> wro= te:

> Hi all,
>
> I see that the leading zero is stripped off of the value of Z (the sha= red secret) before it is used as input to HKDF. This seems to be compatible= with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which= uses the value of Z with the same size of the prime in octets. Furthermore= , it is also different with regards to handling the coordinate X as used in= ECDH.
>
> Was this a conscious decision to keep compatibility with TLS? Has the = use of the value of Z including zero octets been considered?
>
> Regards,
> Maarten

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--047d7b874aba6a463f0535b5c1b1--