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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Mar 2016 16:31:54 +0100

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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>>> <[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/
>
> - --
>>>>
> Marc Petit-Huguenin
> Email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWyiOZAAoJECnERZXWan7EpAwQALT42q+uWbjk9qfPZmJI4dzU
> EKhNuQw+yJZ6Pk0TO5EbLtbLb0U9huWIXfL/qnMhoZKmtyBI05yL08KIIucJQJ74
> Y/vTcVuYhminD4Ug8p4ytu9v5RotexQFbomFKqZP3TC0hCISrrWbbg+LU0EEPpZM
> jT+D8pYdzAXGEYQvZ8k9xq/rjZfksYLjQOUPLHgoCC1L3wzr3xvswKQ7c0NEoSC8
> rDbVxTp4f+q15W3/HG29+wFN6npgapFK49bXPzAR2LYTHO8yw6mHpHMEd3zq9Kd/
> HsdOWH2ETqFiLOaszFO+rzQPx+/OsEwZWDTf2tcKLamogCoKfRJKICmFWAvHSf9G
> 56aiBiwL6kdKZHIcOJ4zQZqG7UdZ1pVy78czPfkjSwB8TD1RMFXNwS6WTgF9RmYy
> Ixe1lrvzOdfrL02NvGz2DdEAM7ETS9ujIxbrOUTEg6d7IDJ7FQdT97zHxvCUfjLY
> kDd4RtVqIr825+78uJxeXCJ5fZfXOG0VbwpwlC2smyxHUUVwTWQMCJ32EvZynuFo
> f7yNMkdSolr3C2Bkt5ELwnKxUtiTqFMZj52rtBzhqAN6iDt289JSvO1e87EORBin
> N1ingAw1bEJz1raNF0uA8u7N12QUtAsPrc9hYpmYjxl6I3+d/lFevvmWne/YbWbU
> UduqXpPezcNInD7bMDOD
> =J64B
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 

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]
----------------------------------------------------------------------

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 2 Mar 2016 14:08:28 -0800

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.

On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund <
[email-masked]> wrote:

> visible. Such a simple motivation fulfil the coordination requirement as I
> see it.
>
>> 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.
>>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 2 Mar 2016 15:20:06 -0700

> this registration request will work with TLS 1.3 or any future version of

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.

> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Mar 2016 09:48:00 +1100

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

I think that we can resolve this by saying this instead:

RFC 5764 describes a narrow use of DTLS that works as long as the
specific DTLS version used abides by the restrictions on the first
byte (the ones that mux-fixes wants to put in the TLS registry).  Any
extension or revision to DTLS that no causes DTLS to no longer meet
these constraints prevents that extension or version from being used
in the fashion RFC 5764 describes.

That means that DTLS 1.2 is safe.  Thus far.  DTLS 1.3 is also safe so
far, though we're a lot further from done there[3].

I'm sorry that I didn't see this option before; I figured that with
content type encryption in TLS 1.3, we wouldn't need those code
points.  However, Joe is right to protest the incursion onto sovereign
territory.

[3]  I actually hope that we can change DTLS 1.3 so that it won't mux
properly.  That will have a size benefit that should outweigh the cost
of having to rev 5764 for 1.3.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Mar 2016 16:25:23 +0100

Hi,

To be clear I will not continue with a publication request while we are 
having a discussion. I hope we can resolve this with an agreement on how 
to proceed.

Den 2016-03-02 kl. 23:48, skrev Martin Thomson:
>> 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.
> in the fashion RFC 5764 describes.

Sorry, I am not certain I understand what you suggest. Do you want the 
above text in RFC 5764, or as a comment in the TLS content type 
registry, or what?

> far, though we're a lot further from done there[3].

It is "Thus far" comment for DTLS 1.2 that is one reason that we want to 
put in sufficient warnings into the TLS content type registry. And 
clearly DTLS 1.3 will also have to take into account this. It is one out 
of many usages of DTLS, but it is not insignificant amount of usage that 
relies on the possibility to separate the protocols on first byte.

> points.  However, Joe is right to protest the incursion onto sovereign

I want to make it clear that the goal is to have something that is 
mutually agreeable here. The situation with the multiplexing is already 
existing and widely deployed, whatever one thinks of it. The goal with 
the update is to clarify the situation, resolve uncertainties and points 
of confusion, as well as reducing the risk for future issues due to 
ignorance.

> of having to rev 5764 for 1.3.

I really hope before that decision is taken that one analyse and propose 
a solution for how to handle the need for multiplexing so that 
discussion has happened.

Cheers

Magnus Westerlund
AVTCORE WG chair

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 15 Mar 2016 19:40:19 +0000

I think this draft needs WGLC in all the WGs where it limits the existing code space. 

> On Feb 7, 2016, at 10:21 PM, Joseph Salowey <[email-masked]> 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.  
> 
> 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).
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 15 Mar 2016 19:44:11 +0000

> On Mar 15, 2016, at 1:40 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> 

Somehow hit send trying to move this from one computer to another before finishing it. But what I was going on to say was ...

but that was happening and given the current rate of usage of TLS, this did not seem like a restriction that was likely to significantly limit TLS future extensions.