IETF Logo Mail Archive

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

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 15 April 2015 19:00 UTC

Return-Path: <Andrei.Popov@microsoft.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 DBA2B1A8899 for <tls@ietfa.amsl.com>; Wed, 15 Apr 2015 12:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level:
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, 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 O6I3mHy0qzbl for <tls@ietfa.amsl.com>; Wed, 15 Apr 2015 12:00:22 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4811A8852 for <tls@ietf.org>; Wed, 15 Apr 2015 12:00:16 -0700 (PDT)
Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) by BN3PR0301MB1267.namprd03.prod.outlook.com (0.161.209.147) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 18:59:57 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 18:59:55 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 18:59:55 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
Thread-Index: AQHQdjMVLAECbtqN1ke7Q3E3qycYJJ1Le3aAgAAAZTCAAAq6gIABR+AAgABQyQCAAKuogIAAljgggAAJIACAAALpIA==
Date: Wed, 15 Apr 2015 18:59:55 +0000
Message-ID: <BN3PR0301MB1250C1D685D10C9F3747BF538CE50@BN3PR0301MB1250.namprd03.prod.outlook.com>
References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> <BN3PR0301MB12509693B1F91EAA100F18958CE50@BN3PR0301MB1250.namprd03.prod.outlook.com> <CABkgnnUU5E76o9g7em57xujaKtqg5ApH=9Mtm3MHpc3uyi8G+Q@mail.gmail.com>
In-Reply-To: <CABkgnnUU5E76o9g7em57xujaKtqg5ApH=9Mtm3MHpc3uyi8G+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1267;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(19580395003)(93886004)(19580405001)(86612001)(76176999)(86362001)(54356999)(122556002)(99286002)(102836002)(50986999)(40100003)(2950100001)(2900100001)(77156002)(62966003)(33656002)(46102003)(74316001)(2656002)(110136001)(87936001)(92566002)(106116001)(76576001)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <BN3PR0301MB1252759431F788C75B3A4A9E8CE50@BN3PR0301MB1252.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1252; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252;
x-forefront-prvs: 0547116B72
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 18:59:55.2534 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IBh24UbxQURJKKAkx_HkDAJR4Zk>
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
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, 15 Apr 2015 19:00:24 -0000

Since the ALPN RFC allows the use of octet strings as ALPN IDs, it seems wrong to characterize non-ASCII IDs as "junk" or "crazy" values. ALPN IDs are not intended for display to the user, and don't have to consist of ASCII characters.

It is true that one could implement an API that only takes NUL-terminated ASCII ALPN IDs. Such an API would be limited in that it's only useable with a subset of allowed ALPN IDs (but admittedly some people can live with that). It is more important that the ALPN I-D matching code treat the IDs correctly, as length-prefixed byte arrays.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, April 15, 2015 11:38 AM
To: Andrei Popov
Cc: Hubert Kario; mrex@sap.com; tls@ietf.org
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned

On 15 April 2015 at 11:14, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> Having said that, ALPN RFC allows the use of arbitrary octet strings as ALPN IDs, so unfortunately the simple API that assumes NUL-terminated ASCII IDs is not sufficient. And of course any code that matches ALPN IDs has to perform the comparison of byte arrays rather than some form of string comparison.


Well, you *could* implement something that only took NUL-terminated ASCII labels.  That could still work, even if it encountered junk as long as the implementation correctly checked lengths first.  It would only fail to work if you actually need to talk to someone who wanted to include a crazy value.

v2.23.0 | Report a Bug | By Email