Re: [TLS] Simplifying signature algorithm negotiation

[Eric Rescorla <[e-mail]>]

On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin <[e-mail]>
wrote:

> On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla <[e-mail]> wrote:
>
>> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <[e-mail]>
>> wrote:
>>
>>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <[e-mail]> wrote:
>>>
>>>> - 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).
>>
>
> Gotcha. This is true independent of this change, right? Without it, we'd
> need to define two v1.5 SignatureAlgorithm values instead.
>

Correct.


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

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



> Anyway, I think this is orthogonal. We can certainly allocate more v1.5
> code points in either universe if people want that. *shrug*
>
> David
>
>
>> -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 <[e-mail]>
>>>> wrote:
>>>>
>>>>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <[e-mail]> wrote:
>>>>>
>>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <[e-mail]>
>>>>>>> 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
>>>>>
>>>>
>>>>