Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 31 July 2014 15:30 UTC

Return-Path: <fluffy@cisco.com>
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 7C5FC1A00D7; Thu, 31 Jul 2014 08:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -113.902
X-Spam-Level:
X-Spam-Status: No, score=-113.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 Gl4TNWuO7l0L; Thu, 31 Jul 2014 08:30:55 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18651A00AB; Thu, 31 Jul 2014 08:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2511; q=dns/txt; s=iport; t=1406820654; x=1408030254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7Mx8Mf/Q4t4V3KcaHhJ6/ppgjt39tjh0Wsg5E5tu9nk=; b=Rke4XeqSYHBHAqj+iiDU038jJhMwoTWIWhK4+MgJ+Worzaa1vzbdGP2H wEo/QOUHPLbK1oPr+ND+sE7/Pn/UB4L1rXYViMLGPORIMXHYmvBcfy7N7 IRoBPaM3rCK8/RugzGHhb/3uHM4t0PH6Yqb66qs9azuCZSP61/GKOTUY3 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAOlf2lOtJA2L/2dsb2JhbABagw5SVwTLL4dJAYEHFneEAwEBAQECASdSBQsCAQgYLjIlAgQOBYg6CA2/dxeOewEBHDMCBYMvgRsFm2SBUpMBg0lsAYELOQ
X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344186002"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2014 15:30:53 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6VFUreg013865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 15:30:53 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 10:30:53 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [tram] [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
Thread-Index: AQHPpp82fjgNGTILOE6Hla7Sj7WHspuuY6YAgAxLyoA=
Date: Thu, 31 Jul 2014 15:30:52 +0000
Message-ID: <A96AAFCA-0B31-48B4-84FD-89AE582C9B64@cisco.com>
References: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp>
In-Reply-To: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.70.167]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FF3A1E6EB356264899AC38450C038AFE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23BUai3MOuqC3LhhxOckraFA4zk
Cc: "tls@ietf.org" <tls@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
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: <http://www.ietf.org/mail-archive/web/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: Thu, 31 Jul 2014 15:30:57 -0000

On Jul 23, 2014, at 12:44 PM, Martin Rex <mrex@sap.com> wrote:

> Cullen Jennings (fluffy) wrote:
>> 
>> We should make a new IANA registry that keeps track of for each value
>> of the first byte, which protocol it is allocated to. I would suggest
>> that it require "Standards Action? to allocate a new code point to a
>> protocol but of course one allocated to that protocol, the protocol
>> would manager it within it?s existing IANA registry for that protocol
>> with that protocols existing rules. 
>> 
>> The advantage of this is we can allocate the points as needed instead
>> of guessing if TLS or STUN  or some new protocol will need a given
>> number points. There is no implementation problem for the demux because
>> things that use the new code points would know how to demux them. 
> 
> I'm slightly confused.  Is that first byte in Figure 3:
> 
> http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00#page-6
> 
>                    +----------------+
>                    | 127 < B < 192 -+--> forward to RTP
>                    |                |
>        packet -->  |  19 < B < 64  -+--> forward to DTLS
>                    |                |
>                    |       B < 2   -+--> forward to STUN
>                    +----------------+
> 
>     Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
>          Here the field B denotes the leading byte of the packet.
> 
> the actual "ContentType" byte of the (D)TLS record protocol,
> which happens to currently be visible on the outside of the (D)TLS
> record protocol with a fairly small set of values:
> 
>      enum {
>           change_cipher_spec(20), alert(21), handshake(22),
>           application_data(23), (255)
>       } ContentType;
> 
> 
> There has been a proposal to hide the ContentType for TLSv1.3
> and break lots of existing software that relies on being able
> to parse TLS records:
> 
> https://www.ietf.org/mail-archive/web/tls/current/msg13055.html
> 
> 
> Will rfc5764 have to be added to the list of things that would break
> by such a (needless) TLSv1.3 change?
> 

my understanding of the proposal would be they would use and existing record or create a new code point but that code point would be in the 19 to 64 range so I don’t think RFC 5764 would be broken by the proposal.  The proposal might still be sort of lame but I don’t think it breaks this demux.