Re: [TLS] Simplifying signature algorithm negotiation

Eric Rescorla <ekr@rtfm.com> Tue, 15 March 2016 23:06 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 209AE12DE4A for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 16:06:55 -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 RI2i2pjGdvyK for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 16:06:52 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 4A61B12DE56 for <tls@ietf.org>; Tue, 15 Mar 2016 16:06:45 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id h129so40996098ywb.1 for <tls@ietf.org>; Tue, 15 Mar 2016 16:06:45 -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=309xqfWdGx7UJ+bQGYFfIv2T+HS3OOateZLLpY1cYRM=; b=NOCYx5nHE0d1isAncFn1u7IVCvxnnCwLtP/xV7fLIgeQ8LHzhmj/G2qb15KwSKvNII r4vR8Ny0ujnholIxA+CKuGYokM66fB8+fnX/a5XQQxqmDVswEb1WZStj74P8LYehGYvR kekluQrP92HmExSpqO3NHqlDBVjp+S95JFdSEdXYUJEIjJhmM5QjfCv4BBQiKjyGvYef TvqpTvGB1dudTvcH764onO82oUQYJ8WnxMevngageUgDSaqI5nh4mcVNt5Xw7RBZCTcn 4keQcmDdq1c6wU/y64VFkIyCpOLc/nl36DUU4/c2+ygxV8o1ovqYHG4dTZzvo/BirNnY yulA==
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=309xqfWdGx7UJ+bQGYFfIv2T+HS3OOateZLLpY1cYRM=; b=auh9lMoL/3bpgiD3uzyKzw87qnepuHJf7XsQV+ubKs5xaRgNY9PmAfaYbGchRDlZYn Hiaez2hjfe+MFTbFxDCXdgV5OIUw3bDyvdCwgt0EUBvOEAfaHGRwHgB5SYflt6ZuoABB ycIV+X9amXclIPFB0O0A+eO31l9v1ABLjrmBlPpiZOkKwDuGNepAZ4GOvMDbwIdsp9Bl JM0hT6kQnf6+NaKGgm7FzZIfXGNIKUu/rbNNWd0L1N8XazscJlYvgXgAkAheTiWiO0en zuK4862ocNbqroj+U6FqNQIqxq6FFFdZr9c8JLqIfGmrMJITO4l/cEqkZqciwg9MuKqu HtWA==
X-Gm-Message-State: AD7BkJJ1iq7ggJB327qMbcW2GaRwsAHD1YE9DDCVVmMdDHmIAutheaoSxGxwXYSjR/m4YZ3UHrpEsui91f0PCg==
X-Received: by 10.37.230.202 with SMTP id d193mr332377ybh.74.1458083204350; Tue, 15 Mar 2016 16:06:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Tue, 15 Mar 2016 16:06:04 -0700 (PDT)
In-Reply-To: <CAF8qwaDdi9JNNKUCBsuQmw3AssaiKvMgSs_8bCebfmBRdzCAQw@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> <CABcZeBMGnma86M24hzQw6zmwftMte2Lr34TGuq2pUF0MTGZMUQ@mail.gmail.com> <CAF8qwaDdi9JNNKUCBsuQmw3AssaiKvMgSs_8bCebfmBRdzCAQw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 15 Mar 2016 16:06:04 -0700
Message-ID: <CABcZeBPUM4YmeUfzE8_jj6CqOQ5t1Q-82kU7jA3xg1XF+Pd0ng@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=94eb2c0afb0e732850052e1e7348
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ltM6q0kIbUnhmo7SQy6HbW4SHyA>
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 23:06:55 -0000

On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <davidben@chromium.org>;
wrote:

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

Like I said, it's a balance :)



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 think we concluded that they weren't forbidden, but I believe it would be
best if
they generally matched.


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

The idea here would be that we want to be able to deprecate the use of v1.5
in
CertificateVerify before its us in certs (which we can't deprecate for
quite some
time).

-Ekr


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