Re: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

[Dave Garrett <[e-mail]>]

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
> <[e-mail]> 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/