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

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

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