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

Martin Thomson <martin.thomson@gmail.com> Sun, 30 November 2014 07:31 UTC

Return-Path: <martin.thomson@gmail.com>
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 73FC11A03A9 for <tls@ietfa.amsl.com>; Sat, 29 Nov 2014 23:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z09_wxvZkG8u for <tls@ietfa.amsl.com>; Sat, 29 Nov 2014 23:31:06 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB77B1A03A3 for <tls@ietf.org>; Sat, 29 Nov 2014 23:31:06 -0800 (PST)
Received: by mail-oi0-f47.google.com with SMTP id v63so6193765oia.6 for <tls@ietf.org>; Sat, 29 Nov 2014 23:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cfzKEBr8EIYt2mO94xa8465zDGQVgR1FtDl8PkZLdyw=; b=Dmd8fJQtBST3RSs5TeZKoUkw44eMZoCmlSUHAGEt8aVr/imGyHMcpLhwdagxvD+/Qr 3NOpzH620BHhLKalYKwKevjnCzxZB8YML44jsmYuaaxTvhB9monxofIfk/3jOt0bM36m E3AB1FAZPIVe/A+cFpuhFVWNm+XkJIk5qnEk/nUFc7cvEwOkA+4JOaFIc56lOWb7StSG q58wLyjcnznNdJdc/IRBch74qkISSjpDfCBVzSCIKra9pCCkOT4uYIH0O7fe/aqVq39M gt+LZRmuQDLS3tqVKvbfnt7czNal/GSUNIyABMUQNEzid5qE47S/lklBL/gBAn1rbVat Us4A==
MIME-Version: 1.0
X-Received: by 10.182.16.138 with SMTP id g10mr3694560obd.85.1417332665915; Sat, 29 Nov 2014 23:31:05 -0800 (PST)
Received: by 10.202.115.4 with HTTP; Sat, 29 Nov 2014 23:31:05 -0800 (PST)
In-Reply-To: <03BB9FA7-C0DD-4E05-A041-666354A6362C@pahtak.org>
References: <AA93BAA4-5C5F-4969-8DF6-A83287D80F6D@ieca.com> <AFF9C4EE-6BCA-4AA6-BAB5-A457CDCC67AA@gmail.com> <D1DCDF76-5CA4-442C-852B-30A88EF3B1B1@pahtak.org> <CABkgnnUNK4be3WYzdrTv43UZmxDW2MVOH4Xmc-mS_06Db7Xbwg@mail.gmail.com> <03BB9FA7-C0DD-4E05-A041-666354A6362C@pahtak.org>
Date: Sat, 29 Nov 2014 23:31:05 -0800
Message-ID: <CABkgnnUe=6Ty99XP-xvAHQ=q1+FcU4FAau3bB2AwUcK+weVsUQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Stephen Checkoway <s@pahtak.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b9nlRUg40PwQSmP_xfZJEks1Q-A
Cc: "TLS@ietf.org (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: Sun, 30 Nov 2014 07:31:08 -0000

On 29 November 2014 at 12:38, Stephen Checkoway <s@pahtak.org> wrote:
>
> On Nov 29, 2014, at 2:37 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> If the certificate is selected based on the cipher suite (ECDSA, for
>> instance), maybe there is a desire to have a uniform chain so that a
>> client doesn't end up in a situation where they can't verify the chain
>> (because they don't have RSA, for example).
[...]
> I think that's reasonable. TLS 1.2 specifies
>
>    If the client provided a "signature_algorithms" extension, then all
>    certificates provided by the server MUST be signed by a
>    hash/signature algorithm pair that appears in that extension.
>
> and it also specifies what the defaults are when that isn't sent. I imagine similar text could be used here.

We can probably do better: https://github.com/tlswg/tls13-spec/issues/99