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 < magnus.westerl...@ericsson.com> 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 +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
