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

mrex@sap.com (Martin Rex) Wed, 23 July 2014 19:44 UTC

Return-Path: <mrex@sap.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 CE5641B2CBE; Wed, 23 Jul 2014 12:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.952
X-Spam-Level:
X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 euaakBhbyUFw; Wed, 23 Jul 2014 12:44:45 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B34041A014F; Wed, 23 Jul 2014 12:44:44 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6NJidZW008268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 21:44:39 +0200 (MEST)
In-Reply-To: <CE9DACA8-F719-44E0-B085-7B615FE16C34@cisco.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Date: Wed, 23 Jul 2014 21:44:38 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NSlqWwn77qkMTQtFoH-wyqSXxWs
Cc: "tls@ietf.org" <tls@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 23 Jul 2014 19:44:47 -0000

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?


-Martin