Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned

mrex@sap.com (Martin Rex) Mon, 13 April 2015 21: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 83D1D1A8909 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 14:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 QqO83jdtpYc4 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 14:44:55 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100D51A894B for <tls@ietf.org>; Mon, 13 Apr 2015 14:44:55 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id BE4254473D; Mon, 13 Apr 2015 23:44:53 +0200 (CEST)
X-purgate-ID: 152705::1428961493-0000765A-05140CCE/0/0
X-purgate-size: 888
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B46D14358B; Mon, 13 Apr 2015 23:44:53 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AC7AB1B281; Mon, 13 Apr 2015 23:44:53 +0200 (CEST)
In-Reply-To: <BN3PR0301MB1250C67CE251D36E3D5958EC8CE70@BN3PR0301MB1250.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Mon, 13 Apr 2015 23:44:53 +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: <20150413214453.AC7AB1B281@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8EJdq5xwQYxfuhej7WdvA9dUpBE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
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: Mon, 13 Apr 2015 21:44:56 -0000

Andrei Popov wrote:
> 
> Although the currently defined ALPN IDs consist of printable characters
> (which admittedly helps when looking at network traces), generally
> speaking ALPN IDs are octet strings and could contain arbitrary bytes.

I do understand what the current specification (rfc7301) says.

But I just fail to see a rationale why it needs to be that artificially
awkward with no pressing need.

Being able to handle (rather than being allowed to reject upfront)
arbitrary octet string blobs here makes it extremely painful to
implement APIs for this.  You can not allow the pretty common
0-terminated strings API semantics if embedded 0 characters are
permitted, and might get registered in the future.

I'm wondering what specific rationale (other than calling for trouble)
justifies making this extension extra painful to implement and use?


-Martin