[TLS] Updated text in regards to draft-ietf-avtcore-rfc5764-mux-fixes

[Magnus Westerlund <[e-mail]>]

TLS WG,
(Cc AVTCORE WG)

When AVTCORE run a WG last call earlier this year on "Multiplexing 
Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension 
for Datagram Transport Layer Security (DTLS)":
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/

There was several comments from the TLS WG in regards to the update of 
the TLS content type registry as well as the limited applicability of 
the multiplexing scheme used.

The authors have written an updated text proposal. I would really 
appreciate if you could review these changes and provide any feedback.

A diff between the previously WG version and the current one:
https://www.ietf.org/rfcdiff?url1=draft-ietf-avtcore-rfc5764-mux-fixes-05&url2=draft-ietf-avtcore-rfc5764-mux-fixes-07

The update TLS related text is:

4.  Implicit Allocation of New Codepoints for TLS ContentTypes

    The demultiplexing scheme in [RFC5764] dictates that if the value of
    the first byte is between 20 and 63 (inclusive), then the packet is
    identified to be DTLS.  For DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]
    that first byte corresponds to the TLS ContentType field.
    Considerations must be taken into account when assigning additional
    ContentTypes in the code point ranges 0 to 19 and 64 to 255 so this
    does not prevent demultiplexing when this functionality is desirable.
    Note that [RFC5764] describes a narrow use of DTLS that works as long
    as the specific DTLS version used abides by the restrictions on the
    demultiplexing byte (the ones that this document imposes on the TLS
    ContentType Registry).  Any extension or revision to DTLS that causes
    it to no longer meet these constraints should consider what values
    may occur in the first byte of the DTLS message and what impact it
    would have on the multiplexing that [RFC5764] describes.

    With respect to TLS packet identification, this document explicitly
    adds a warning to the codepoints from 0 to 19 and from 64 to 255
    indicating that allocations in these ranges require coordination, as
    described in this document.  The proposed changes to the TLS
    ContentType Registry are:

    OLD:

    0-19    Unassigned
    20      change_cipher_spec
    21      alert
    22      handshake
    23      application_data
    24      heartbeat
    25-255  Unassigned

    NEW:

    0-19    Unassigned (Requires coordination, see RFCXXXX)
    20      change_cipher_spec
    21      alert
    22      handshake
    23      application_data
    24      heartbeat
    25-63   Unassigned
    64-255  Unassigned (Requires coordination, see RFCXXXX)

As document shepherd I intended to run a new WG last call in a weeks 
time, so please provide feedback quickly so that we know if this update 
is okay, or needs additional revisions.

Cheers

Magnus Westerlund
AVTCORE WG chair


----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------