Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin <[e-mail]>]

On Fri, Jan 15, 2016 at 10:13 PM Brian Smith <[e-mail]> wrote:

> David Benjamin <[e-mail]> wrote:
>
>> (Whether such certificates exist on the web is probably answerable via CT
>> logs, but I haven't checked.)
>>
>
> Me neither, and I think that's the key thing that would need to be checked
> to see if my suggestion is viable.
>

Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more
often than not.
https://crt.sh/?CN=%25&iCAID=1516

But it's not actually all that many hostnames (all of which presumably
don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change,
and whether sigalgs are stronger than a hint w.r.t. X.509 is...
controversial. I wasn't able to find anyone else doing it. So +1 from me on
dropping the 3x3 product to just the three you listed.

I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_*
allocations, but I can't think of any weird behaviors, so it seems
reasonable.

(The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a
client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and
yet still speaking TLS 1.2 would have problems. But if we're actually
limiting to those three, that can't happen anyway, and this hypothetical
client seems pretty weird.)

If other people still want to allow ecdsa_p384_sha256 and friends, I'm also
happy with allocating 6 values and throwing out
ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512.

David