Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Ilari Liusvaara <> Tue, 26 July 2016 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6703812D594 for <>; Tue, 26 Jul 2016 03:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Omt3_tJwXqyI for <>; Tue, 26 Jul 2016 03:33:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F69D12D180 for <>; Tue, 26 Jul 2016 03:33:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9294B833 for <>; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 18u1TEnBakNq for <>; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 426D9C4 for <>; Tue, 26 Jul 2016 13:33:02 +0300 (EEST)
Date: Tue, 26 Jul 2016 13:32:57 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
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: Tue, 26 Jul 2016 10:33:06 -0000

On Tue, Jul 26, 2016 at 07:48:05AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara <> writes:
> >I recently (tried to) implement(ed) TLS 1.2 ciphersuite negotiation in a way
> >that always negotiates something if at least one valid configuration exists,
> >and respects TLS 1.2 rules.
> >
> >The resulting code was totally insane, and I am very much not surprised to
> >see buggy implementations. Nor can I say my implementation is not buggy, as
> >testing that mess is just about impossible (and it it will very much do GIGO
> >in order to maximize interop).
> Do you have any more details on some of the issues you ran into?  It'd be good
> to know for anyone else in this situation.
> (I've had to do the same thing, with awkward logic that backs off and retries
> different options if an earlier attempt fails.  This was one of the motivators
> for the Grigg's Law cipher-suite handling in TLS-LTS).

The basic problem (let's ignore non-cert modes for a bit):

When choosing the certificate, you need to consider if you have a
ciphersuite that can use some supported group and protection/prf-hash

Similarly, when choosing a group, you need to consider that you have
a ciphersuite that is consistent in other (possible) choices.

And protection/prf-hash also has to be consistent with other

The reason these choices couple is because the client can send
pretty much arbitrary combination of oters that depends on each
considered factor.

And the selections have to be consistent: The current leading
hypothesis about this interop issue is that certificate selection
consisers ciphersuite valid candidate when protection selection does

TLS 1.3 negotiation revamp would solve this by ensuring that
whichever you choose first, you don't restrict choice on others
(PSK modes are special here, so need to be chosen first[1]), so
whatever you have chosen so far, there either is next valid
choice, or the whole problem has no solution.

[1] There are some couplings here too, but one only needs to check
group overlap for ke and signature/cert overlap for auth (and these
overlap decisions can be used for normal dhe/cert anyway). And one
does not need to consider interaction of those two.