Subject: Re: [TLS] Simplifying signature algorithm negotiation

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Mar 2016 17:21:59 -0700

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 <[email-masked]>
wrote:

> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <[email-masked]> wrote:
>
>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <[email-masked]>
>> wrote:
>>
>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <[email-masked]>
>>> 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
>

---

From: David Benjamin <[email-masked]>
Date: Tue, 15 Mar 2016 17:37:20 +0000

On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <[email-masked]> wrote:

> (thus motivating orthogonal negotiation) versus whether we're going to
> want little flexibility
> negotiation were a lot stronger, but now that we seem to be leaning
> towards (a) fewer algorithms

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.

> - It seems like we could let measurements tell us what code points we
> need. If we never see

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

>   right. I made comments.

Fixed those. Apparently I shifted most of the hashes by one. Sorry about
that!

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Mar 2016 16:06:04 -0700

On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <[email-masked]>
wrote:

>> and (b) having algorithms which are themselves suites, I do agree that
>> the pendulum is swinging
>> more towards suites.
>>
>

Like I said, it's a balance :)

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

> 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

>>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm.
>>>>>> In TLS
>>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it
>>>>> and forgot.
>>>>>
>>>> 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 :)
>>>>
>>>
>>> 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
>>>
>>
>>

---

From: David Benjamin <[email-masked]>
Date: Thu, 17 Mar 2016 00:47:21 +0000

On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla <[email-masked]> wrote:

>>> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then
>>> we'll probably want to define
>>>
> The idea here would be that we want to be able to deprecate the use of
> v1.5 in

Gotcha. This is true independent of this change, right? Without it, we'd
need to define two v1.5 SignatureAlgorithm values instead.

I'm not sure this is worth the nuisance. If we expect to deprecate it soon,
we should just keep it out of 1.3. If not, we only need to advertise
removal if there are v1.5-preferring servers that can sign anything else,
in which case why aren't they signing that to begin with? Otherwise
rejecting v1.5 is going to break those servers regardless. (Then again,
with SHA-1 vs. SHA-256 in ServerKeyExchange, I myself found
SHA-1-preferring SHA-256-capable servers, which is baffling. Would be good
if 1.3 implementers didn't repeat that one...) Should we split all other
code points in anticipation of deprecating them? Why not a separate
extension altogether then?

Anyway, I think this is orthogonal. We can certainly allocate more v1.5
code points in either universe if people want that. *shrug*

David

>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <[email-masked]
>>>>> > wrote:
>>>>>
>>>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and
>>>>>>> negotiate that
>>>>>>> > instead.
>>>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Mar 2016 05:33:15 -0700

> need to define two v1.5 SignatureAlgorithm values instead.

Correct.

> extension altogether then?

I don't think we will be deprecating 1.5 for certs soon. I do see your
point about
1.5 for CertificateVerify

>>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <
>>>>>> [email-masked]> wrote:
>>>>>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 17 Mar 2016 19:34:37 +0200

> AES_128_GCM required separately negotiating block cipher AES-128, mode CTR,

It isn't even orthogonal, it is coupled, which is way worse and quite
difficult to implement correctly.

I now consider the way TLS 1.3 draft / RFC4492bis draft currently does
EdDSA negotiation a bad idea (what is proposed here is vast improvement).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Mar 2016 10:50:40 -0700

It sounds like we have general consensus here. Does anyone object to my
merging
this PR?

-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 20 Mar 2016 17:27:29 -0700

No objection,  it looks good.  I don't see any objections on the list so I
say merge it.

On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara <
> [email-masked]> wrote:
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Mar 2016 19:18:39 -0700

Acknowledged. This will be in draft-12.