Re: [TLS] Simplifying signature algorithm negotiation

[Brian Smith <[e-mail]>]

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.

3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
>> (I don't have any particular affinity for that profile other than it seems
>> to have made choices that have historically been shown to be above average,
>> and it might be a good idea to avoid interop failure with other
>> implementations that might have a special affinity for it.)
>>
>
> What interop faliures are you worried about here?
>

The way I proposed things to work for TLS 1.3 is what the Suite B profile
does for TLS 1.2. A Suite B client cannot describe the Suite B profile
policy with the signature_algorithms extension as-is, so in theory if a
Suite B profile client even exists, it would work better if servers assumed
that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't
know if any such "Suite B client" actually exists, though.


> I don't think it makes sense to strategically assign the second byte for
> new numbers. Either we believe TLS 1.2 implementations are unlikely to
> react to 0x0703 and not worry about it, or we believe they will and we
> reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
> u16 hack is too silly and don't do it at all.)
>

I would bet there will be some logic like "Is sha-256 mentioned at all in
the signature_algorithms extension" and/or "is ecdsa mentioned at all in
the signature_algorithms" extension that is used by some servers to decide
whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think
it would be worth the effort at least when the effort is minimal.

Cheers,
Brian
-- 
https://briansmith.org/