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.
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.)
5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> rsapss_{sha256,sha384,sha512}.
>
This seems like a good idea to me.
> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
> a subset of X.509's RSA-PSS.
>
I believe this is already largely taken care of in TLS 1.3 by fixing all
the parameters to be a function of the digest algorithm used for the
message.
- 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.
> 0xfe00-0xffff - reserved for private use, compatible with existing
> HashAlgorithm reservation.
>
> [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.
[1] https://tools.ietf.org/html/rfc6460
Cheers,
Brian
--
https://briansmith.org/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
