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

"Ryan Sleevi" <> Mon, 01 December 2014 08:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA6DE1A1A09 for <>; Mon, 1 Dec 2014 00:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rzx7MqS92uDe for <>; Mon, 1 Dec 2014 00:56:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EFC7A1A1A13 for <>; Mon, 1 Dec 2014 00:56:38 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id AF0292AC06A; Mon, 1 Dec 2014 00:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s=; bh=WUdDd6OlI9kjWb3CboDnZ8swBDQ=; b=srXbdIBjq26LFco77 MpDfGueW/eqVE+UbXOVXDwPJtgqcqfXqdLQ9V84d/sedD39bczdkczQPhVFo2Xlm HCwNUqoB8XKVWJLy03wdP/Uy5QCXaYsdwsRE8kuQH6TH96oVRgB22SlBpjviAkr1 8WitDzudXcVkPQpfOZwcqSZ/fo=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 729BE2AC059; Mon, 1 Dec 2014 00:56:38 -0800 (PST)
Received: from (proxying for (SquirrelMail authenticated user by with HTTP; Mon, 1 Dec 2014 00:56:38 -0800
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
Date: Mon, 01 Dec 2014 00:56:38 -0800
From: Ryan Sleevi <>
To: Martin Thomson <>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 08:56:41 -0000

On Sun, November 30, 2014 11:17 pm, Martin Thomson wrote:
>  On 30 November 2014 at 13:52, Stephen Checkoway <> wrote:
> > How is the signature algorithm any different from the cipher suite in
> > this respect? If the client says it can only do ECDSA, what's the point
> > of giving it an RSA cert that it cannot use?
>  I think that the difference is that - at least for most clients - they
>  support both.  Or at least, servers have been able to deploy ECDSA
>  certs that chain to RSA with the expectation that RSA hasn't gone away
>  yet.  And that's relatively new.
>  Peter refers to the fact that servers (and CAs) have picked a
>  certificate that works based on what they know of clients, and had
>  just the one.  That single cert is offered unconditionally.  If the
>  client doesn't like it, then it can be responsible for choking on it.
>  CAs could have offered a range of certificates with varying strength
>  and signature algorithms, but one is always easier in every regard.
>  Migrating away from mostly RSA might have changed that a little.

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)