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

Martin Thomson <> Mon, 01 December 2014 07:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C97F1A1ADF for <>; Sun, 30 Nov 2014 23:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gib9eID-WyIA for <>; Sun, 30 Nov 2014 23:17:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12F3E1A1ADB for <>; Sun, 30 Nov 2014 23:17:22 -0800 (PST)
Received: by with SMTP id gq1so7241974obb.26 for <>; Sun, 30 Nov 2014 23:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IRLfYcsGVxYeJtaNq668UKE6o3AIjmnk99A0CMSXRGc=; b=jZJi0RE8apDGv8JQxrWQiiez/HAVSGL5GlD6ejMwSyz6Sb4ej7QMl/35mmSh6c8SGV z39UiE45V0m8ShBDmt4pZBe4NGbABbLkTIUGIabx3m92SjMr7HpKpDE4dHFumkKWo5gr FHkCyPh5zfkXHundOyCnvMdFjyV3r/zTez3EUQWULPEn8s7IVwpz+t5qXqDacAGT0Vfz VWoE2rNU21j4SYV735NjurUFRPJoRtzaLUYLIC8svUjPCEFO1gXxChybB8sH0bQAQTLk jmcvUNbVl3pU0aZRHppLlgYOQhLjVzox66rHswnifoLR7JUlpZkKykAbHhO6wFokc+c1 4EnQ==
MIME-Version: 1.0
X-Received: by with SMTP id y188mr6866804oig.94.1417418241274; Sun, 30 Nov 2014 23:17:21 -0800 (PST)
Received: by with HTTP; Sun, 30 Nov 2014 23:17:21 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Sun, 30 Nov 2014 23:17:21 -0800
Message-ID: <>
From: Martin Thomson <>
To: Stephen Checkoway <>
Content-Type: text/plain; charset="UTF-8"
Cc: "<>" <>
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 07:17:23 -0000

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.