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

[Magnus Westerlund <[e-mail]>]

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