Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Ilari Liusvaara <> Mon, 01 December 2014 09:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 181D01A1A19 for <>; Mon, 1 Dec 2014 01:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6dlvkS1LnsxD for <>; Mon, 1 Dec 2014 01:33:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04B731A0145 for <>; Mon, 1 Dec 2014 01:33:19 -0800 (PST)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 7971B1A2617; Mon, 1 Dec 2014 11:33:16 +0200 (EET)
Date: Mon, 01 Dec 2014 11:33:16 +0200
From: Ilari Liusvaara <>
To: Ryan Sleevi <>
Message-ID: <20141201093316.GA4986@LK-Perkele-VII>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Cc: Stephen Checkoway <>,
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
X-Mailman-Version: 2.1.15
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: Mon, 01 Dec 2014 09:33:21 -0000

On Mon, Dec 01, 2014 at 12:56:38AM -0800, Ryan Sleevi wrote:
> Plus, there are plenty of libraries where the ciphersuite implementation
> is semi-independent of the certificate validation.
> Perhaps the largest deployment is Chrome, which uses a separate TLS
> library (NSS, BoringSSL) than its PKI validation (OS APIs such as
> CryptoAPI, Security.framework, or Android Keychain Services). You can
> certainly have skew where the TLS client supports a modern suite of
> algorithms, but the underlying platform does not. On Windows XP, this is
> the SHA-2 family (pre-SP3) and ECDSA (pre-Vista), and on OS X, some
> releases had some buggy ECDSA handling.
> There are also a number of embedded TLS stacks that provide the
> cryptographic framework for TLS, but then defer to external components (or
> hardware) for trust validation.
> I just mention these as real world cases where ciphersuites alone are
> insufficient (although SignatureAndAlgorithms generally is... except where
> it isn't)

Plus, it is easier to implement just ECDH than ECDSA over given curve,
so implementations that can do ECDH over curve X but not ECDSA over
curve X (but can do ECDSA over some other curve) should not be surprising.

This might especially be so for CFRG curves.

Vice versa might also happen (can do ECDSA over X, but not ECDH over

Also, the algorithm lists can't specify restrictions like that ECDSA
P-256 only works with SHA-256 and P-384 only works with SHA-384 (because
code to do P-256 with SHA-384 is buggy).