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

Stephen Checkoway <> Mon, 01 December 2014 14:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4B22C1A1BC2 for <>; Mon, 1 Dec 2014 06:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i4DxlW-aOOBu for <>; Mon, 1 Dec 2014 06:28:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D7E31A1BB8 for <>; Mon, 1 Dec 2014 06:28:17 -0800 (PST)
Received: by with SMTP id i17so7700345qcy.18 for <>; Mon, 01 Dec 2014 06:28:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9TtgMW4AUasVq9184X55Mznnlp4j2SFaFb8eLhYTf50=; b=DLS160ClZv//DunwXiyaOChuSPXPhZGP4b52b7M2ho9msaxTHU7971Ib3fl4W5lcD5 ZMTSB6A1qTQZzTWGc3vmdsdGMQc6uC4R9KbPCfBR/X5AGdI+InbefDssB7ufVBSc7vRx fig2cwZXUBQ0Sy7Dn0ZIdjlxtiG79AvSqfvNlaX1z/Flbnkh6YDFBcUm4hu1scolYqos PissujWpiqc+MbpR36LyhYfHjTdQTxsxNVeTrDPJakWl+FSix0qaNslYqAF5+va7IezU 9Jb3TUx6O15Xu0ibH48byOgPEqSMRpTFVvyJ9QAVJLU2h6kuaXsFdCxeUH6qTYW7bDse MpHg==
X-Gm-Message-State: ALoCoQko6nF3pG+2mvJZ5gCQMK1KdXmYGQ3SiwWIuYXZmaWL8vSWoIsKHiL+SmqH+PSC4ByYBMV0
X-Received: by with SMTP id f5mr13257092qai.49.1417444096505; Mon, 01 Dec 2014 06:28:16 -0800 (PST)
Received: from ([]) by with ESMTPSA id w75sm17411815qgd.14.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 06:28:15 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 61275AC287F; Mon, 1 Dec 2014 09:28:13 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <>
In-Reply-To: <>
Date: Mon, 01 Dec 2014 09:28:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1878.6)
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 14:28:19 -0000

On Dec 1, 2014, at 2:17 AM, 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.

And clients can indicate that they support multiple options. I think there's something that I'm missing. A client can indicate that it supports {sha1, sha224, sha256, sha384, sha512} x {rsa, dsa, ecdsa} (I assume no one wants to support md5 any longer).

The quoted text that Peter objected to required all certs in the chain to be signed with one of the specified algorithms. It doesn't require the entire cert chain to be signed by the same algorithm.

If the issue is that the extension takes an extra 36 bytes to specify all combinations and people don't want to waste the bytes on the wire, then that seems like a reasonable concern to me. But that's not what I took Peter's point to be.

> 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.

Sure, but I don't see how that changes the analysis any. If a client supports n algorithm pairs, it can specify those n pairs. I don't see how this makes it a "nonsensical requirements in TLS 1.2 that you pretty much have to ignore in order to get an implementation that works." But again, I'm probably missing something here.

Stephen Checkoway