-----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 >> <magnus.westerl...@ericsson.com> 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: m...@petit-huguenin.org 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
