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

Marc Petit-Huguenin <petithug@acm.org> Wed, 02 March 2016 22:20 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 358571B32DE; Wed, 2 Mar 2016 14:20:18 -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 HMH4uQTqFBQa; Wed, 2 Mar 2016 14:20:16 -0800 (PST)
Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id 17E341B32DD; Wed, 2 Mar 2016 14:20:16 -0800 (PST)
Received: from [IPv6:2602:ae:1762:1200:b842:b7a9:cab9:49c1] (unknown [IPv6:2602:ae:1762:1200:b842:b7a9:cab9:49c1]) (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 756EB20171; Wed, 2 Mar 2016 23:20:14 +0100 (CET)
To: Joseph Salowey <joe@salowey.net>, Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <56A8904D.10307@ericsson.com> <CAOgPGoBU+h6cA9RDxBX2m1AR-3-GnC7OYcfDLTpDepX00g73dA@mail.gmail.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <CAOgPGoB669zcdqMYXd0yD4Tkqx7yuj6dc0y1byv3bw1ZN_qv6Q@mail.gmail.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <56D76716.1090506@acm.org>
Date: Wed, 2 Mar 2016 15:20:06 -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: <CAOgPGoB669zcdqMYXd0yD4Tkqx7yuj6dc0y1byv3bw1ZN_qv6Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OV3W3pWxO5KvCk6pwdeR7Tuurxa1uBAfS"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0B_o53burhbyxuOLBKMkecsDFfE>
Cc: "tls@ietf.org" <tls@ietf.org>, avt@ietf.org
Subject: Re: [TLS] [AVTCORE] 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: Wed, 02 Mar 2016 22:20:18 -0000

On 03/02/2016 03:08 PM, Joseph Salowey wrote:
> Reserving large portions of other protocols number spaces is not a good way
> to do things.   This will quickly become unworkable if other protocols
> decide to do the same thing.  This type of behavior needs to be
> discouraged.  There is no guarantee that the multiplexing scheme prompting
> this registration request will work with TLS 1.3 or any future version of
> TLS.

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.

This draft just put an emphasis on the fact that allocating ContentType codepoints in the ranges that *RFC5764* reserved can have consequences.

> 
> On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
> 
>> 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:
>>
> 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/
>>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> 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.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug