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

[Joseph Salowey <[e-mail]>]

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