On Thu, Jun 27, 2019, at 03:32, Sean Turner wrote:
> The IANA DEs (Designated Experts) think that the registry should
> indicate that the connection_id is DTLS-Only. This is the first
> extension defined that would need this marking. Currently, there is no
> “DTLS-Only” column in the TLS ExtensionType Values registry nor is
> there a "DTLS-OK" column like there are in the TLS Parameter registries
> [0]. Note none of the TLS extension registries [1] have a "DTLS-OK”
> column.
Let's look at something less interesting than this, like the use_srtp
extension. The current conception of that is DTLS-Only, but it turns out that
it makes a lot of sense to negotiate that in QUIC, which is essentially TLS and
not DTLS. It's fairly simple to update the IANA registry when defining the new
usage, but that can be done by adding a reference to a new document.
So for me the question is how much detail you need to capture in the registries
as opposed to the spec. The spec can capture a ton of nuance that the registry
can't. We won't ever manage to tabulate all the properties of registered
values; so the question is whether there is some value in having that
information available in this form. I can't see that here.
Worse, if we say DTLS-OK=N for an extension, is that a license to kill a
connection if a client offers that extension? The same applies to any
codepoint that might be so restricted. That would prevent the use of use_srtp
in QUIC, so we'd need a new codepoint if we wanted the same semantics. That's
a strictly worse situation than where we are today.
I strongly prefer doing nothing.
p.s.,
I went through the registries and the ones listed below with an X don't - in my
opinion - need the DTLS-OK column. In all of these - except as noted - all
registered values have a Y as far as I can see. So my view is that only the
cipher suites need the column, and only for historical reasons that no longer
apply to any suite we might newly define.
X TLS ClientCertificateType Identifiers
TLS Cipher Suites
X TLS ContentType
X TLS Alerts
X TLS HandshakeType - why is EOED marked DTLS-OK when it is prohibited?
X TLS Supported Groups
X TLS EC Point Formats
X TLS EC Curve Types
X TLS Supplemental Data Formats (SupplementalDataType)
X TLS UserMappingType Values
X TLS SignatureAlgorithm
X TLS HashAlgorithm
? TLS Exporter Labels - this uses the DTLS-OK=N heavily, but that is because
the usage for those exporters is in TLS and never DTLS, there is no inherent
reason for the column to be present
X TLS Authorization Data Formats
X TLS Heartbeat Message Types
X TLS Heartbeat Modes
N/A TLS SignatureScheme - no column
N/A TLS PskKeyExchangeMode
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
