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

Magnus Westerlund <> Thu, 03 March 2016 15:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 13C241A004A; Thu, 3 Mar 2016 07:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HuA49oW4_rnq; Thu, 3 Mar 2016 07:25:26 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E4C71A0060; Thu, 3 Mar 2016 07:25:25 -0800 (PST)
X-AuditID: c1b4fb30-f79d26d000006389-67-56d857640915
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 06.B9.25481.46758D65; Thu, 3 Mar 2016 16:25:24 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 3 Mar 2016 16:25:23 +0100
To: Martin Thomson <>, Marc Petit-Huguenin <>
References: <> <> <> <> <> <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Thu, 03 Mar 2016 16:25:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM2K7hG5K+I0wgy0r+C1e9qxkt1j+p4vR Ytum/ewW1878Y7S4sOYuk8Wn812MDmwel694e+ycdZfdY8mSn0wex3dtYA9gieKySUnNySxL LdK3S+DK+L2epWCaRMXtedeZGxinCHcxcnJICJhIzP10kQXCFpO4cG89WxcjF4eQwGFGiUsP t0M5yxglHn3+yw5SJSwQJtH/7iQjiC0iEC5xdfoNRoiiNmaJpVO3gHUwC3QzSqw4u5cVpIpN wELi5o9GNhCbV0BbouP4f7B9LAIqEruuN4PViArESBx/d44RokZQ4uTMJ2A1nAKBEgf3X2cG sZmB5sycf54RwpaXaN46GywuBDSzoamDdQKj4Cwk7bOQtMxC0rKAkXkVo2hxanFSbrqRkV5q UWZycXF+nl5easkmRmCwH9zy22AH48vnjocYBTgYlXh4N6y4HibEmlhWXJl7iFGCg1lJhDck 4EaYEG9KYmVValF+fFFpTmrxIUZpDhYlcV7WT5fDhATSE0tSs1NTC1KLYLJMHJxSDYyTq01V +aoaIjtO8cSdDo4X/p5onmMXeLy4YUcc/66vQTINCyJmWMV2bE3L2v6R24F/hnnDuvLJptMd VUym/7w3IzkiK7B10zver482WDq+a/O8/u13Vi1b5bmca21z17H9OZjXWHqKYVf2xqfbb2/T aq+qfK7q2q34WfNwi8i5qedkQywC5ZVYijMSDbWYi4oTATFNA+NyAgAA
Archived-At: <>
Cc: Dave Garrett <>, Joseph Salowey <>, "" <>, "" <>
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: Thu, 03 Mar 2016 15:25:30 -0000


To be clear I will not continue with a publication request while we are 
having a discussion. I hope we can resolve this with an agreement on how 
to proceed.

Den 2016-03-02 kl. 23:48, skrev Martin Thomson:
> On 3 March 2016 at 09:20, Marc Petit-Huguenin <>
> wrote:
>> draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large
>> portions
of the ContentType codepoints, RFC 5764 did. The damage is already done
as RFC 5764 is deployed as a component of RTCWeb.
> I think that we can resolve this by saying this instead:
> RFC 5764 describes a narrow use of DTLS that works as long as the
> specific DTLS version used abides by the restrictions on the first
> byte (the ones that mux-fixes wants to put in the TLS registry).  Any
> extension or revision to DTLS that no causes DTLS to no longer meet
> these constraints prevents that extension or version from being used
> in the fashion RFC 5764 describes.

Sorry, I am not certain I understand what you suggest. Do you want the 
above text in RFC 5764, or as a comment in the TLS content type 
registry, or what?

> That means that DTLS 1.2 is safe.  Thus far.  DTLS 1.3 is also safe so
> far, though we're a lot further from done there[3].

It is "Thus far" comment for DTLS 1.2 that is one reason that we want to 
put in sufficient warnings into the TLS content type registry. And 
clearly DTLS 1.3 will also have to take into account this. It is one out 
of many usages of DTLS, but it is not insignificant amount of usage that 
relies on the possibility to separate the protocols on first byte.

> I'm sorry that I didn't see this option before; I figured that with
> content type encryption in TLS 1.3, we wouldn't need those code
> points.  However, Joe is right to protest the incursion onto sovereign
> territory.

I want to make it clear that the goal is to have something that is 
mutually agreeable here. The situation with the multiplexing is already 
existing and widely deployed, whatever one thinks of it. The goal with 
the update is to clarify the situation, resolve uncertainties and points 
of confusion, as well as reducing the risk for future issues due to 

> [3]  I actually hope that we can change DTLS 1.3 so that it won't mux
> properly.  That will have a size benefit that should outweigh the cost
> of having to rev 5764 for 1.3.

I really hope before that decision is taken that one analyse and propose 
a solution for how to handle the need for multiplexing so that 
discussion has happened.


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: