Re: [TLS] Simplifying signature algorithm negotiation
David Benjamin <davidben@chromium.org> Tue, 15 March 2016 17:37 UTC
Return-Path: <davidben@google.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 3D0B912DBA6 for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 10:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 u6THbgD8YIza for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 B38CC12DBA2 for <tls@ietf.org>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id g203so32976470iof.2 for <tls@ietf.org>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=RPNDP9xc1NejRfxcUVg7lqqpAt4g6I+/AA4b/X5pBxTO1We/cMxLpNoFAN6eQuAmXg +IumGuSoKAv8tYKdgw5uawgnGIGmhLzXjN16s4txw//sKSE5982mWTcXbhc3xrM7TTeJ iKd6Xs5+yHkMAQs/AvwVKEVqMYyu05GGnEcN0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=DXG3PehY2EDGKdt4+/1RZByZ8cnTJsmdYBB/Ej574dcMBm1VJ1EV3d0WQLQK0eslaK rx+b5TrYRGR1U9E/lZUDJ5+TyMUIl/CadHIMtJ4vniNzYEk5/8I0oncvd/IsVWv5WvuY hkQdtkI+Jcx5pXJV03MDSyRlS8g2fhvZMnwX2ZUtGNzy9hD6jHZli5wKHwX2zbSdLUiv 8149t3z8rjEb2MOSTbll8Qiw7XLL6t+Uyhg+dF32kcuxgS+oBlLyo7OAoA/SsPGTn0bh fCSBTyzUxA1d0ppAm4b/7Ptf72GeqfE7fEaAIT9Npca6ufVbyIYRFXR1e2stBCRfOOCQ fM2Q==
X-Gm-Message-State: AD7BkJJzLzFn/Q0mtZyaB65SFYRpUnOTetFJM6WeVe3QZ2mH3JlrtOcHhpHn5kAwohJ5xQyNW186snTwuDa88jYH
X-Received: by 10.107.165.140 with SMTP id o134mr36840179ioe.62.1458063449483; Tue, 15 Mar 2016 10:37:29 -0700 (PDT)
MIME-Version: 1.0
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> <CABcZeBMGnma86M24hzQw6zmwftMte2Lr34TGuq2pUF0MTGZMUQ@mail.gmail.com>
In-Reply-To: <CABcZeBMGnma86M24hzQw6zmwftMte2Lr34TGuq2pUF0MTGZMUQ@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 15 Mar 2016 17:37:20 +0000
Message-ID: <CAF8qwaDdi9JNNKUCBsuQmw3AssaiKvMgSs_8bCebfmBRdzCAQw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1141fb90f7ca83052e19d9ba"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dI6i_Vpeuo_qHlyqqR6wkzwrhy4>
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 17:37:33 -0000
On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com> wrote: > 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. > I would probably characterize it less as suites vs orthogonality, but as wanting to keep divisions in meaningful and universal places and not splitting up tightly-coupled decisions. The flexibility from orthogonality can be handy, but going too far---as I believe TLS 1.2 did with signature, prehash, and curve---complicates everything. Imagine if negotiating AES_128_GCM required separately negotiating block cipher AES-128, mode CTR, and MAC GHASH. 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 guess this relates to the fun issue of how TLS sigalgs interacts with X.509. If we believe they are at most a hint for X.509, then I think we can freely declare that TLS 1.3+ requires curve/hash matching for NIST curves. Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign P384-SHA256. If we believe that non-matching certificates are forbidden in TLS, then, yeah, it's a concern. I searched CT logs some time ago and found some cases of P384-SHA256, but that was it. https://www.ietf.org/mail-archive/web/tls/current/msg19089.html I went with the small set for the draft text since it's a little cleaner and seemed to be what most preferred, but I would be fine with allocating P384-SHA256 too. Or maybe all 6 non-truncating values. (Or even the full 9 from my original proposal but, as others pointed out to me, P256-SHA384, P256-SHA512, and P384-SHA512 are kinda silly.) - 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. > Fixed those. Apparently I shifted most of the hashes by one. Sorry about that! > - 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. > Oh? Why would they need to be separate? The others defined for both aren't. David > 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