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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 May 2016 11:51:26 +0200

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 17 May 2016 14:06:44 -0700

Hi Magnus,

The revision addresses the comments I had.  If anyone else still has
concerns please respond this week.

Thanks,
Joe

On Mon, May 16, 2016 at 2:51 AM, Magnus Westerlund <
[email-masked]> wrote:

> 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)":
> 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.
>
> 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
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>