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

Marc Petit-Huguenin <petithug@acm.org> Sun, 21 February 2016 20:52 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36971ACDA5; Sun, 21 Feb 2016 12:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.636
X-Spam-Level:
X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7MuW4SyHZHN; Sun, 21 Feb 2016 12:52:51 -0800 (PST)
Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id DA48D1ACDA8; Sun, 21 Feb 2016 12:52:50 -0800 (PST)
Received: from [IPv6:2602:ae:177f:9f00:f486:e1a7:6cf7:c359] (unknown [IPv6:2602:ae:177f:9f00:f486:e1a7:6cf7:c359]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3E779200E3; Sun, 21 Feb 2016 21:52:49 +0100 (CET)
To: Dave Garrett <davemgarrett@gmail.com>, tls@ietf.org
References: <56A8904D.10307@ericsson.com> <CAOgPGoBU+h6cA9RDxBX2m1AR-3-GnC7OYcfDLTpDepX00g73dA@mail.gmail.com> <201602080117.57742.davemgarrett@gmail.com>
From: Marc Petit-Huguenin <petithug@acm.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <56CA239F.6010107@acm.org>
Date: Sun, 21 Feb 2016 13:52:47 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0
MIME-Version: 1.0
In-Reply-To: <201602080117.57742.davemgarrett@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/nUV9DBvEIOXIBcJrC-5Je5eEz5k>
Cc: avt@ietf.org
Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2016 20:52:52 -0000

-----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.westerlund@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: marc@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-----