IETF Logo Mail Archive

[TLS] draft-ietf-tls-rfc4492bis-15 and the X25519 significant bit.

David Benjamin <davidben@chromium.org> Wed, 15 March 2017 20:25 UTC

Return-Path: <davidben@google.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 D1F7113181A for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 13:25:47 -0700 (PDT)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 GAgv0vFn0p-3 for <tls@ietfa.amsl.com>; Wed, 15 Mar 2017 13:25:46 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 EB36B1317F9 for <tls@ietf.org>; Wed, 15 Mar 2017 13:25:45 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id x63so8270572pfx.2 for <tls@ietf.org>; Wed, 15 Mar 2017 13:25:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=oeh/hIXCANxcYQO9t/g7TYXJd9k6VTzFXx9T2NuyJU0=; b=QPQmQ3gm8sDLaBufPgrp98Cz7tTpQWznnpqerdZYjpbtvkRT4GJrOj5+g1fjG44L7+ JGlICE1xcQfnAdm60zDyAk3cun92GIg2mrhIOt7QR2F7gMXoDj9SoaxZRsIhAik7ZXX9 +FG3Tn0bbR57iIkCNEMkSZI6XCAla3gfBZG2k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oeh/hIXCANxcYQO9t/g7TYXJd9k6VTzFXx9T2NuyJU0=; b=NTn2ffEXVdZ+WZOE4MzSsbeVWwkMgHyh9pLVPm6jP3iQoV7zymAQig1xKLsssKkGva 6ZC5ErBgyOVXAh87FAU+imj9wcnXEPKvIP3LTbz+BxZWILt8pfcDuBvGyTmKuLfs7J/b VtEbZaIh+DoaaJbj4YQWjrQ/My5pMRNzb5Wc5vbsLviHHAKQ0ASQYLs0D9Kq95eIJFdM HJhTvoPukinFp2PW+Rred+JuSrc1lDdlD2WniTFl0wup+dK/1p5tOftovYq25171Ehr1 sYRXWSw3037XFyV0262T7KJtqUjf0TiLL2IDFWMaKQ+f2DJ4lKOCLQmFotUqiLYiFT1o RFtA==
X-Gm-Message-State: AFeK/H154ocnz6lU1HuH3Hf1XnYJ7kJcc2GN4raxExTEEwn3oaeUMOGwYl8Fyd5x0ThWNVSnPq5rxiXCkeaITnG0
X-Received: by 10.84.232.198 with SMTP id x6mr7014255plm.74.1489609545230; Wed, 15 Mar 2017 13:25:45 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Wed, 15 Mar 2017 20:25:34 +0000
Message-ID: <CAF8qwaBCf-GCx3Y_a+G_ODsWmdm8sgUsjPN+LyQ=7-n0iOO-6w@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043621c8cc7290054acabf99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/InAMwzSFG_UGNqWqBLnnlNS6OHQ>
Subject: [TLS] draft-ietf-tls-rfc4492bis-15 and the X25519 significant bit.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Mar 2017 20:25:48 -0000

draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:

   Since there are some implementation of the X25519 function that
   impose this restriction on their input and others that don't,
   implementations of X25519 in TLS SHOULD reject public keys when the
   high-order bit of the final byte is set (in other words, when the
   value of the rightmost byte is greater than 0x7F) in order to prevent
   implementation fingerprinting.  Note that this deviates from RFC 7748
   which suggests that This value be masked.

https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-15#section-5.11

There was a thread about this way back, but it seems not to have come to a
clear conclusion:
https://www.ietf.org/mail-archive/web/tls/current/msg18821.html

Since then, RFC 7748 has been published and X25519 in TLS has been shipped
by several implementations. From my testing, none of BoringSSL, Cloudflare
servers (tls-tris?), Go, NSS, or OpenSSL implement this check. They all
mask off that bit, as RFC 7748 prescribes. (These were all the
implementations I tested.)

RFC 7748 provides a function on bytes, so, barring strong reasons not to, I
think it is best for TLS to simply reference RFC 7748 as-is. The stated
motivation is preventing implementation fingerprinting, yet all the
implementations listed mask. This paragraph also does not align with the
current TLS 1.3 draft.

Thus, I would suggest the paragraph be removed from the document. It would
then prescribe RFC 7748's behavior which is to mask off that bit. Do others
agree?

David

v2.23.0 | Report a Bug | By Email