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