Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

"D. J. Bernstein" <> Sun, 20 March 2016 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAE4D12D6C5 for <>; Sun, 20 Mar 2016 07:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1VpMWk1cwQjh for <>; Sun, 20 Mar 2016 07:38:23 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 8B1E2127058 for <>; Sun, 20 Mar 2016 07:38:21 -0700 (PDT)
Received: (qmail 516 invoked by uid 1017); 20 Mar 2016 14:38:46 -0000
Received: from unknown (unknown) by unknown with QMTP; 20 Mar 2016 14:38:46 -0000
Received: (qmail 20818 invoked by uid 1000); 20 Mar 2016 14:33:55 -0000
Date: 20 Mar 2016 14:33:55 -0000
Message-ID: <>
From: "D. J. Bernstein" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Approved-At: Sun, 20 Mar 2016 18:11:31 -0700
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
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: Sun, 20 Mar 2016 14:38:26 -0000

Peter Gutmann writes:
> compressed points are patented

Which patent are you referring to?

US 6141420, I suppose. Let's ignore the question of what's in the prior
art (1992 Harper--Menezes--Vanstone) and what's actually claimed in the
patent. Are you aware that this patent expired in July 2014?

> Everything uses uncompressed points at the moment without any problems

The same way that everyone uses C and C++ without any problems? completely broke
two implementations of uncompressed (x,y) ECDH in TLS. The problem, of
course, is that the implementors forgot to check that the input (x,y)
was on the curve.

OpenSSL _does_ try to check, but it seems that this check is sometimes
affected by recently announced bugs in OpenSSL's carry handling. The
impact isn't clear---analyzing this sort of thing is very difficult.
Using compressed (x,y) significantly reduces the amount of rarely tested
checking code for the implementor to screw up.

More importantly, there's a third option (introduced in Miller's
original ECC paper), namely using just x-coordinates. Section 4.1 of explains how X25519 uses this third
option to proactively and robustly avoid this type of attack.