On 20/11/2019 04:58, Benjamin Kaduk wrote:
> Quoting from RFC 6347:
>
> DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11].
> This document introduces a new version of DTLS, DTLS 1.2, which is
> defined as a series of deltas to TLS 1.2 [TLS12]. [...]
>
> The presumption should be that anything defined for TLS (1.2) is also
> defined for DTLS (1.2); if you look at things in any of the IANA
> registries that are marked as DTLS-OK(N), you'll find that they are few
> and far between, and that there is some (cryptographic) reason why they
> are incompatible with DTLS usage, which can involve (e.g.) out-of-order
> delivery and retransmission. E.g., RC4 is a stream cipher and can't
> handle out-of-order delivery, so TLS_ECDH_RSA_WITH_RC4_128_SHA is
> DTLS-OK(N).
>
> The two signature algorithms in question are pretty bog standard
> cryptographic primitives, and only get used in the handshake anyway, so
> it's pretty clear to me that hey are rightly marked as DTLS-OK(Y).
>
> I could only find the AUTHj48 discussions in my mail archives; it's
> possible that the IANA discussions happened before I was responsible AD.
> If you're still uncertain after the above, we can try to dig up some
> more history of where the DTLS-OK(Y) came from.
This is ok as an answer but it means there is no traceability of entries
in the registry to RFCs that specify those entries - and that can lead
to confusion. That has happened in this case (those signature schemes
are explicitly coded as TLSv1.2 only in OpenSSL).
If you take the line that "anything specified for TLSv1.2 is implicitly
ok for DTLSv1.2 unless stated otherwise", then I at least think an RFC
should have a minimal nod towards DTLS. At least to give the message
that "yes, we have considered this in a DTLS setting and its fine". As
you state above there are exceptions, so we do need to consider this on
a case-by-case basis. In the case of RFC8422, as a minimum I would have
expected that to be in the form of a sentence saying that those entries
should have DTLS-OK against them in section 9 - especially as the
following paragraph *does* say this for the "Intrinsic" HashAlgorithm
registry entry (rather implying by omission that this doesn't hold for
ed25519/ed448).
Matt
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
