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

From: Joseph Salowey <[email-masked]>
Date: Sun, 7 Feb 2016 21:21:02 -0800

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.

Cheers,

Joe

On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund <
[email-masked]> 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/
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dave Garrett <[email-masked]>
Date: Mon, 8 Feb 2016 01:17:57 -0500

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:
> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund
> <[email-masked]> wrote:
> 
> > AVTCORE and TLS,
> >

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 21 Feb 2016 13:52:47 -0700

On 02/07/2016 11:17 PM, Dave Garrett wrote:
> Permanently gobbling up the majority of the codespace feels like
> excessive force here. 

This is not what the RFC-to-be is proposing.  We are just marking the values that can create an issue when used with RFC 5764 as reserved, with a note in the IANA registry that ask to read the RFC-to-be to understand the problem.  If a new proposed ContentType codepoint will never ever be used in the context of RTCWeb, then it can be allocated in the reserved range.

> 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.
> 
>> 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.
>> 
>> 
>>> 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).
>>> 

- --
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug