Return-Path: <s@pahtak.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 4B22C1A1BC2
 for <tls@ietfa.amsl.com>; Mon,  1 Dec 2014 06:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
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 mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id i4DxlW-aOOBu for <tls@ietfa.amsl.com>;
 Mon,  1 Dec 2014 06:28:17 -0800 (PST)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com
 [209.85.216.173])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 4D7E31A1BB8
 for <tls@ietf.org>; Mon,  1 Dec 2014 06:28:17 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id i17so7700345qcy.18
 for <tls@ietf.org>; Mon, 01 Dec 2014 06:28:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; 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 10.224.64.197 with SMTP id f5mr13257092qai.49.1417444096505;
 Mon, 01 Dec 2014 06:28:16 -0800 (PST)
Received: from zbox.pahtak.org ([68.48.196.126])
 by mx.google.com with ESMTPSA id w75sm17411815qgd.14.2014.12.01.06.28.14
 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 ip-122-171.wireless.oberlin.edu
 (ip-122-171.wireless.oberlin.edu [132.162.122.171])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by zbox.pahtak.org (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 <s@pahtak.org>
In-Reply-To: <CABkgnnV4JUoS3jV_vp4KV_xX-wdXa4ART7gtMd7BUZMapELRLw@mail.gmail.com>
Date: Mon, 1 Dec 2014 09:28:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCCCC38B-C021-47CB-A5DF-A614326F3161@pahtak.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz>
 <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org>
 <CABkgnnV4JUoS3jV_vp4KV_xX-wdXa4ART7gtMd7BUZMapELRLw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P0H3hHiLp6U-1K9JV6piBY2B7nU
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>,
 <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 01 Dec 2014 14:28:19 -0000


On Dec 1, 2014, at 2:17 AM, Martin Thomson <martin.thomson@gmail.com> =
wrote:

> On 30 November 2014 at 13:52, Stephen Checkoway <s@pahtak.org> 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?
>=20
> 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.


--=20
Stephen Checkoway