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

[Joseph Salowey <[e-mail]>]

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 <
[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:
>
>> -----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
>>>> <[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/
>>>>>
>>>>
>> - --
>>
>>>
>>>>> Marc Petit-Huguenin
>> Email: [e-mail]
>> 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
>> [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
>