Permanently gobbling up the majority of the codespace feels like excessive force here. For TLS 1.3, the first byte will always be one of alert(21), handshake(22), or application_data(23), even for custom types. The stated type for TLSCiphertext has been frozen to application_data(23) with the actual type for the payload now in the encrypted fragment. (this is of course assuming we don't eventually drop the frozen type & version here, which now sounds unlikely if we're having to deal with design flaws like this) Even handshake records after the hellos will have an opaque_type of application_data(23), with the encrypted fragment.type containing the actual handshake(22) designation. All TLS 1.3+ packets will be detected with the RFC 5764 Section 5.1.2 algorithm even if new types are allocated in the proposed reserved ranges.
Locking down the <1.2 registry seems fine, however 1.3+ should be able to do whatever it needs as its encrypted type is not going to get accidentally read & misinterpreted by anything. https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 https://tools.ietf.org/html/rfc5764#section-5.1.2 https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4 Dave On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: > This document is relevant to the TLS working because it reserves a large > portion of the TLS content type space. The values 0-19 and 64-255 cannot > be used without checking for conflicts with SRTP-DTLS's wacky > demultiplexing scheme. In TLS 1.3 we will move more encrypted content > types which should limit the impact this unfortunate design on TLS > evolution, but the working group should be aware of this. > > > On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund > <magnus.westerl...@ericsson.com> wrote: > > > AVTCORE and TLS, > > > > TLS WG, you are included in this WG last call, as this document affects > > the TLS ContentType IANA registry. > > > > This email starts a two week WG last call, that ends on the 10th of > > February. The intended status of this document is standards track (Proposed > > Standard). > > > > The document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
