Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

Russ Housley <housley@vigilsec.com> Thu, 19 May 2016 19:40 UTC

Return-Path: <housley@vigilsec.com>
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 7EBB912D65F for <tls@ietfa.amsl.com>; Thu, 19 May 2016 12:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 ihv4fHz-hbla for <tls@ietfa.amsl.com>; Thu, 19 May 2016 12:40:11 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4001012DC0A for <tls@ietf.org>; Thu, 19 May 2016 12:40:11 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B9B94F24035; Thu, 19 May 2016 15:40:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 8VnmWyQmFw2Z; Thu, 19 May 2016 15:22:50 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id E55C4F2402A; Thu, 19 May 2016 15:40:09 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0FA6D59C-E20E-44D6-8ABC-D3648037081A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAF8qwaAVfXGAktExjV3pH9GmhuupzRJyujG90kLhVjzWvx9WNg@mail.gmail.com>
Date: Thu, 19 May 2016 15:40:07 -0400
Message-Id: <0FCFE9D6-7396-4BBF-B161-E1ACC36E18CD@vigilsec.com>
References: <CADwHJ+9XCpEDtX6vE+TQXKwz1MEhXHkj5Xbua6vAY_03Q=6LDA@mail.gmail.com> <A58F7462-B9A0-4FFA-AAEB-7C6AA6BCA1C2@vigilsec.com> <CAF8qwaBFY+8HEgMcH4cQg2-3F1qOGzqkeqtqnuFpjYp09+hviA@mail.gmail.com> <CAF8qwaAVfXGAktExjV3pH9GmhuupzRJyujG90kLhVjzWvx9WNg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Du7dX1I53f3DuDodZHkk5MguIdk>
Cc: IETF TLS <tls@ietf.org>
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 19 May 2016 19:40:13 -0000

Thanks for doing the text.

Russ


On May 19, 2016, at 3:22 PM, David Benjamin <davidben@chromium.org> wrote:

> 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 <davidben@chromium.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. 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 <housley@vigilsec.com> 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 <maarten.bodewes@gmail.com> 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