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

[Marc Petit-Huguenin <[e-mail]>]

On 03/02/2016 03:08 PM, Joseph Salowey wrote:
> Reserving large portions of other protocols number spaces is not a good way
> to do things.   This will quickly become unworkable if other protocols
> decide to do the same thing.  This type of behavior needs to be
> discouraged.  There is no guarantee that the multiplexing scheme prompting
> this registration request will work with TLS 1.3 or any future version of
> TLS.

draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large portions of the ContentType codepoints, RFC 5764 did.  The damage is already done as RFC 5764 is deployed as a component of RTCWeb.

This draft just put an emphasis on the fact that allocating ContentType codepoints in the ranges that *RFC5764* reserved can have consequences.

> 
> On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund <
> [e-mail]> wrote:
> 
>> Hi Dave and TLS WG,
>>
>> To my understanding the changes proposed by the
>> draft-ietf-avtcore-rfc5764-mux-fixes is not an issue if any TLS 1.3+
>> extension, i.e. any TLS extension that is not to be used in 1.0-1.2 can
>> safely be allocated in the reserved range as they will not be externally
>> visible. Such a simple motivation fulfil the coordination requirement as I
>> see it.
>>
>> As the AVTCORE WG chair and document shepherd I will continue with a
>> publication request as soon as I done the paper work for it. If you have
>> any additional feedback on this, then please provide it now.
>>
>> Cheers
>>
>> Magnus Westerlund
>> AVTCORE WG chair
>>
>>
>>
>>
>> Den 2016-02-21 kl. 21:52, skrev Marc Petit-Huguenin:
>>
> 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.
>>>>>
>>>>> 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/
>>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> 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
>>
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 

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