On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <br...@briansmith.org> wrote:
> David Benjamin <david...@chromium.org> wrote:
>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduces new premultiplications, it’s only 9 values with the pruned TLS
>> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>>
>
> Have you considered the possibility of using this mapping?:
>
> TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
> TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
> TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.
>
> Then:
> 1. You don't have to define any new values.
> 2. The extension size would be smaller.
>
Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
lose them. I just wrote out all 9 without thinking about it much. Apart
from "please don't cause me interop pain", I don't have strong opinions
about how aggressively we prune the list.
My main worry is, for better or worse (I realize this is a point of
contention), some servers apply sigalgs to both CertificateVerify and
certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a
nuisance.
Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
it would prevent them from adopting TLS 1.3 without switching certificates.
Alternatively, if people decide that sigalgs and certificates officially
have nothing to do with each other in TLS 1.3, then things are fine but we
wouldn't have a way to negotiate such algorithms. I was hoping to avoid
that issue for this proposal, but there is some interaction.
(Whether such certificates exist on the web is probably answerable via CT
logs, but I haven't checked.)
If changing the existing meaning is a nuisance, another option is to
continue to allocate new values but only define ecdsa_p256_sha256,
ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
is) for TLS 1.3 and later.
> 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?
> - ecdsa_p256_sha384
>> - ecdsa_p256_sha512
>> - ecdsa_p384_sha256
>>
> - ecdsa_p384_sha512
>> - ecdsa_p521_sha256
>> - ecdsa_p521_sha384
>>
>
> The subset of your proposed values I listed above do not seem helpful. For
> example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
> truncated to 256 bits.
>
Good point. That makes some of the combinations unlikely.
> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
>> RSA}, they should ignore it since hash 7 doesn't exist.
>>
>
> I think we should expect more pure ECC (no RSA) deployments soon. In that
> case, it would be better if new ECC-based values used the value "ECDSA" (3)
> instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
> as support for RSA.
>
Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with
'ECDSA'. The same footnote applies. :-)
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.)
David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
