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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 26 July 2016 07:48 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 5DCE912B05B for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 00:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 zsdoWS_KzSCN for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 00:48:10 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E2712B028 for <tls@ietf.org>; Tue, 26 Jul 2016 00:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1469519289; x=1501055289; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LKMFl1RATk9PW4xFQ21e5jeNKdYR3I2HeopnvNYHOc4=; b=k+R+BYzHYIaurPgwazdpIiFdj282gU82w5eCExmrimhsy3hBdHi7K4g+ nMMdeuceHm+7Adt744Bt+jmJSCwr2DpdSEjTVGdJrsAoULATbbQ+nATo5 oipnK+844sY87rJX9Bh5CZUbCyIiTThMh46pcn+PMRoc4L9J85LFs2ojA lIC4YTLesWMYx8pOlMlnhoazaimfQW+jWOo6TeDaWJWkQCVZeL3BRiq6/ oXjb+B8+0PJk0iQlcw4QXj9+2w829Y0VOQgmMK2HqHgXg0/gTkZl4d+cv 8pfVYFMLvZ+mHMIfvv0bMZSmXRsf41LQNAaiXCRwl+SGAtAUn03lXstUI A==;
X-IronPort-AV: E=Sophos;i="5.28,423,1464609600"; d="scan'208";a="98934869"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Jul 2016 19:48:06 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 26 Jul 2016 19:48:06 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Martin Rex <mrex@sap.com>
Thread-Topic: [TLS] weird ECDSA interop problem with cloudflare/nginx
Thread-Index: AQHR5qgCNz+FR8k/8Uif+jsgAebuiKAowWEAgAGVRQ4=
Date: Tue, 26 Jul 2016 07:48:05 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CD79E0@uxcn10-5.UoA.auckland.ac.nz>
References: <20160725190849.728521A508@ld9781.wdf.sap.corp>, <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160725193708.GA17319@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.6.3.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MWFHujbm66rW2HhFNIIWqiABaqU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
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: Tue, 26 Jul 2016 07:48:13 -0000

Ilari Liusvaara <ilariliusvaara@welho.com> 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).

Peter.