Re: [TLS] IANA Considerations for draft-ietf-tls-dtls-connection-id

Hi,

I strongly prefer option 3.  The future-proofing and avoidance of a
proliferation of new columns in the IANA registries is paramount.
The points about QUIC highlight the near-term need to clean up
this this issue.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Jun 26, 2019 at 1:32 PM Sean Turner <sean@sn3rd.com> wrote:

> While these IANA points are minor, what is being considered here affects
> all TLS registries so please let us know what you think about the proposal
> for the following issue:
>
>
> Issue:
>
> 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.
>
>
> Proposals (there might be more):
>
> 0. Do nothing
>
> 1. Add a note to the top of the registry that says connection_id is
> DTLS-Only
>
> 2. Add a DTLS-Only column to the TLS ExtensionType Values registry and
> mark this one Y and all others N
>
> 3. Think about the future (inspired by Achiem in the GH repo):
>
> - Change the “DTLS-OK” column to "TLS/DTLS”.  Allow values of TLS, DTLS,
> or TLS/DTLS.
>
> - Mark all DTLS-OK=Y rows to “TLS/DTLS” and all DTLS-OK=N to “TLS”. [2]
>
> - Add “TLS/DTLS” column to the TLS ExtensionType Values registry and mark
> the connection_id extension as “DTLS" and all others as “TLS/DTLS".
>
>
> Selection:
>
> While option 3 is the most work it does kind of future proof the
> registries and would make the columns the same in the parameter and
> extensions registry groupings.
>
>
> spt
>
> [0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
> [1]
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
> [2] Most of the DTLS-OK=N are deprecated cipher suites, but a couple of
> Exporter Labels are also marked as DTLS-OK=N.
>
> > On Jun 20, 2019, at 21:46, Sean Turner <sean@sn3rd.com> wrote:
> >
> > All,
> >
> > During the DE’s review of the assignments for
> draft-ietf-tls-dtls-connection-id, they requested a new “DTLS Only” column
> be added to the TLS ExtensionType Values registry. This connection_id would
> be the only “Y” and all others there now would be “N”.
> >
> > The chairs also noted that the IANA considerations in
> draft-ietf-tls-dtls-connection-id needs to specify values for all the
> columns for connection_id in the TLS ExtensionType Values registry and
> tls12_cid in the TLS ContentType registry.  Here are the proposed values:
> >
> > connection_id
> >       TLS 1.3 column: “-“ it is not applicable to TLS 1.3
> >       Recommended: “Y"
> >
> > tls12_cid
> >       DTLS-OK: “Y”
> >
> > This has been captured in the following PR:
> > https://github.com/tlswg/dtls-conn-id/pull/67
> >
> > Obviously, please comment.
> >
> > spt
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>