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

Marc Petit-Huguenin <> Sun, 21 February 2016 20:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A36971ACDA5; Sun, 21 Feb 2016 12:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.636
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j7MuW4SyHZHN; Sun, 21 Feb 2016 12:52:51 -0800 (PST)
Received: from ( []) by (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 "" (verified OK)) by (Postfix) with ESMTPS id 3E779200E3; Sun, 21 Feb 2016 21:52:49 +0100 (CET)
To: Dave Garrett <>,
References: <> <> <>
From: Marc Petit-Huguenin <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Feb 2016 20:52:52 -0000

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

- --
Marc Petit-Huguenin
Version: GnuPG v2