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

Joseph Salowey <joe@salowey.net> Wed, 02 March 2016 22:08 UTC

Return-Path: <joe@salowey.net>
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 231DC1B32A4 for <tls@ietfa.amsl.com>; Wed, 2 Mar 2016 14:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] 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 pSYJZKXMvKbD for <tls@ietfa.amsl.com>; Wed, 2 Mar 2016 14:08:50 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080211B32A7 for <tls@ietf.org>; Wed, 2 Mar 2016 14:08:50 -0800 (PST)
Received: by mail-lb0-x233.google.com with SMTP id k15so1787232lbg.0 for <tls@ietf.org>; Wed, 02 Mar 2016 14:08:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QAp1M6XeGalusA4y25Oi4wGr2+V2aoszyRO3Qm3NoGA=; b=Jx8Hc+SW/YZMbt+AXF0nXI7uN33y8sxUBN0r8iJwugF6a2Qmtgzh+iLE2H+rk/R2ea f3ofHZuAGOf00thr/bq3Edxy+cr7XopJjDm2EpnpRujf+/525xgJNf2OW4sFxgpFuNKP /2fzgd6IlUbcMGsWbBc29XKNzklP/fcTRn8/kC9gAumNoUNdprINaCIZkHmJZKw5YS5G WAN7TcQuqVSHexQDCI3RR8RJgdP5x9IAgqJvJc70xh55mj4dWqX8Gj5BepveEUKIyUtX aFlOWICwSlkaeNWhcbr1r1rxY1Dq6O7FsOLHbOCjwgqv3BYI3DUcbl7P24cw/8/NqQ5t CQiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QAp1M6XeGalusA4y25Oi4wGr2+V2aoszyRO3Qm3NoGA=; b=V9P5PilI9Pes2YpWTkB4QGSBDi27tb4sQH6MlOCH47QdI/xcN4P180J4qEcSwaiiTh DEwWmnE+FNLyk1hCYuzI2SewGr/zohtAjYOsD6UCcUz3UAaFA6p/7Fu/Jv6lxLMi0Crm ZDLo/ZNucv3HB60XzM/8MIqIFWTr/4l4kYMlk4hK1QPk1HGHS0/ykf3MR8pONgU6kjp9 5nKQfAclX2GGLPlKf/bNIkh3qz/mpVqUT4V9tVd4/LIC83uG45/xV+MDdq4to2KMRS9A 7zX2NfyOoDDdIsf4mA2OxE0yiJN3Hj4qsXGUVuhMzMWXuuaLVrNTfXhlaVuGrljTvzjs r18A==
X-Gm-Message-State: AD7BkJKglPjTrvBV/kIbMN331ZkdFP+eBWi2cHcyT2kYG8D+0SEraax43TfNOwbM/t9ArvXeL+yEp4QaanySKg==
X-Received: by 10.25.169.82 with SMTP id s79mr11341353lfe.47.1456956528066; Wed, 02 Mar 2016 14:08:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.2.104 with HTTP; Wed, 2 Mar 2016 14:08:28 -0800 (PST)
In-Reply-To: <56D7076A.1020703@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>
From: Joseph Salowey <joe@salowey.net>
Date: Wed, 2 Mar 2016 14:08:28 -0800
Message-ID: <CAOgPGoB669zcdqMYXd0yD4Tkqx7yuj6dc0y1byv3bw1ZN_qv6Q@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=001a114106d84f1770052d1820e9
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ee2pWyoks_T2speuipCTBDCk350>
Cc: "tls@ietf.org" <tls@ietf.org>, 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: Wed, 02 Mar 2016 22:08:53 -0000

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.

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