Re: [TLS] Simplifying signature algorithm negotiation
Eric Rescorla <ekr@rtfm.com> Tue, 15 March 2016 00:22 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406612D70F for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 17:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 uLMwH0gOFR0b for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 17:22:40 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C4F12D53B for <tls@ietf.org>; Mon, 14 Mar 2016 17:22:39 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id g127so1787104ywf.2 for <tls@ietf.org>; Mon, 14 Mar 2016 17:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i1AvZJUe/s9Ei8UbXmvqIEmKMvjTmnfHIMcxmr70zGQ=; b=MIcum8U1SBNhQEPnRX6gx97B/7aqZ0H1gBQgRRADPvGGDikKzqBxBBcIi900EVtCm8 PZLClffyFAOrDkJLck8gZrdiuPwbeOI4/7rOltrfUFVnDbqt81Fy+jUCpZHTC0g7BFNS P2UNlmxWXMRiUGMH+sAUbRAW4En38FaZJqPSxpKNSZJ/rSr4tG5grnxgFbtFkYUaAH7H yiZZE1CvbCePaIwk/yHT7u6tkFBVcAyv7QcCSj3q4uN3fm6ndPsvO9Bxr97XXFX4AbGm udiWPvJFulpI+qmaXmr+LrgKp14ZXUguPuadfwWlf8OL7xahZUMujh/7IV+SGlQDIiFT Z0VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i1AvZJUe/s9Ei8UbXmvqIEmKMvjTmnfHIMcxmr70zGQ=; b=kIFwn3U8l0GDqn4cj+9V9irrTAdZ1yKwupKZ9XyFC6gUzOhkrzLj5Ngare5qoa+UeY j195uTvOzkGYVIAmtRpKcRMi7t9NBwqDSC2c/gvAG/9GQG0gh0fuBEO3PGCBchD+aeDv oZjcPYKQ22OWqAhVFMnpxGCJ2bCjR65/7i4ESp6cAx17v64/Fpy0hygqNg9Ht/lU9nVa rAWx2m2vKPvvYdwATiF4aXykeGokwMlLNRIodX40g375e6lvsvy7Apf8vCUP9A/ErwbA Z2z9bPOAPacStmpIljaFGr6sa+7nexQ/iSzsEoFqTH6P9ivd9lnBBOBL+FAICJ13xd5S eD/w==
X-Gm-Message-State: AD7BkJIOrS6yDSKlLaYwc2sT7EE/i+1jPxseCdnlOBcZnQsvOhMzpk4jYc/q0r/kW/TEZhqBHD6b0nNaO2OKlw==
X-Received: by 10.37.13.146 with SMTP id 140mr6609945ybn.159.1458001358939; Mon, 14 Mar 2016 17:22:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 17:21:59 -0700 (PDT)
In-Reply-To: <CAF8qwaDUbLmvzibuC7aedOR5TP6Fv3rNz6ft_v3bKu=FHatYgg@mail.gmail.com>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <201601152007.12464.davemgarrett@gmail.com> <CAF8qwaBPsLz-vuOvXGZgxzMpaKHwtZixu7NXzfFN4V_R6WT8Tg@mail.gmail.com> <CABcZeBNipj4oLU=FrTp3+CqTg5bh5vBnd04DoNt56=8BRjqobw@mail.gmail.com> <CAF8qwaDUbLmvzibuC7aedOR5TP6Fv3rNz6ft_v3bKu=FHatYgg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Mar 2016 17:21:59 -0700
Message-ID: <CABcZeBMGnma86M24hzQw6zmwftMte2Lr34TGuq2pUF0MTGZMUQ@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary="001a11c0417c1525ad052e0b65d8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AaByFCfqbnWHrhWWqwfFY8fZwi4>
Cc: ekr <notifications@github.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 15 Mar 2016 00:22:42 -0000
David, Thanks for being patient with me here. Sorry it took so long As usual, this seems like a question of whether we're going to want a lot of flexibility (thus motivating orthogonal negotiation) versus whether we're going to want little flexibility (thus motivating suites). I think that with the historical practice, the arguments for orthogonal negotiation were a lot stronger, but now that we seem to be leaning towards (a) fewer algorithms and (b) having algorithms which are themselves suites, I do agree that the pendulum is swinging more towards suites. On balance, I guess, I'm neutral-to-supportive of this change in general, if others in the WG want to make it. On the details: - It seems like we could let measurements tell us what code points we need. If we never see P256-SHA512 in the wild, then we don't need it (and can add it later if needed). - I took a quick look at the PR and I'm not sure that some of the code points assignments are right. I made comments. - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll probably want to define code points for 1.5 in both in-protocol (CertificateVerify) and certificates to distinguish these. As far as process, it seemed like people were generally positive about this in this discussion, but I'll rely on the chairs to determine consensus. -Ekr On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <davidben@chromium.org> wrote: > On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote: > >> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.org> >> wrote: >> >>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> >>> wrote: >>> >>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In >>>> TLS >>>> > 1.2, signature algorithms are spread across the handshake. >>>> [...] >>>> > I propose we fold the negotiable parameters under one name. >>>> [...] >>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>> SignatureAndHashAlgorithm as >>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>>> that >>>> > instead. >>>> >>>> I previously proposed this here: >>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>> >>>> ekr was against it, though it hasn't been discussed that throughly. >>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>> >>> >>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >>> forgot. >>> >>> ekr, are you still against this sort of thing? I think the new CFRG >>> signature algorithms tying decisions together is a good argument for why >>> we'd want this. If we believe this trend is to continue (and I hope it >>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>> seems poor. >>> >> >> I'm not sure. I agree that the CFRG thing seems to be a new development. >> I'll >> try to confirm my previous opinion or develop a new one over the weekend >> :) >> > > ekr, did you have confirmed or new thoughts on this change? > > From elsewhere in the thread, I put together a draft PR if you wanted > something to look at in that form. > https://github.com/tlswg/tls13-spec/pull/404 > It incorporated some of the suggestions in the thread (not mentioning the > really legacy values, pairing NIST curves with hashes, etc.), but that's > not the important part. The meat of the proposal is unifying signature > algorithms under one number and a shared interface, which I think is a > valuable simplification. > > David >
- [TLS] Simplifying signature algorithm negotiation David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Brian Smith
- Re: [TLS] Simplifying signature algorithm negotia… Dave Garrett
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Hanno Böck
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Brian Smith
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Nikos Mavrogiannopoulos
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Hubert Kario
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Kurt Roeckx
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… David Benjamin
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negotia… Joseph Salowey
- Re: [TLS] Simplifying signature algorithm negotia… Eric Rescorla