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