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

Andrei Popov <> Wed, 15 April 2015 18:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7E081A0108 for <>; Wed, 15 Apr 2015 11:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wZ4hpoQnLoxp for <>; Wed, 15 Apr 2015 11:14:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA0FD1A012D for <>; Wed, 15 Apr 2015 11:14:58 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 15 Apr 2015 18:14:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 18:14:57 +0000
From: Andrei Popov <>
To: Hubert Kario <>, "" <>
Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
Date: Wed, 15 Apr 2015 18:14:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; 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:BN3PR0301MB1250;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(50986999)(2501003)(76176999)(54356999)(46102003)(19580405001)(19580395003)(62966003)(77156002)(15975445007)(102836002)(15974865002)(87936001)(4001410100001)(74316001)(76576001)(40100003)(86612001)(86362001)(2656002)(2900100001)(99286002)(106116001)(33656002)(2950100001)(92566002)(122556002)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1250;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1250; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1250;
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:14:57.1551 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1250
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Apr 2015 18:15:00 -0000

Martin's desire for a simple API that takes a list of NUL-terminated ASCII strings is very understandable. I've seen other developers ask for the same. 

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.



-----Original Message-----
From: Hubert Kario [] 
Sent: Wednesday, April 15, 2015 2:08 AM
Cc:; Andrei Popov
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned

On Wednesday 15 April 2015 00:53:28 Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Andrei Popov wrote:
> >>> Yes, this is an example of NPN legacy in ALPN, and yes there is 
> >>> some API pain involved.
> >> 
> >> I'm not trying to break things and I'm not advocating to change any 
> >> existing APIs.  But I've just been asked for support of this and am 
> >> looking into newly implementing it, and I would appreciate if we 
> >> (i.e. the IETF TLS working group) could restrict the TLS ALPN IDs 
> >> at least by banning the character 0 from TLS ALPN ID registrations now.
> >> 
> >> Being allowed to reject embedded NULs would facilitate some aspects 
> >> (save me a few lines of code).
> >> 
> >> I can live with UTF8.
> >> 
> >> A single reserved character (such as colon ':' or pipe '|' or comma 
> >> ',') would allow me to avoid a character escaping scheme for the 
> >> API I'm trying to create, but I could live with this issue being a 
> >> proprietary thing.
> > 
> > You don't prevent CVE-2009-2408-like exploits by banning nulls in fields.
> I was talking about *API* stuff, not about wire-level encoding and TLS 
> protocol stuff.

and API needs to be able to handle all the stuff that can be sent over the wire

> To be able to support the currently (unreasonably broad) set of what 
> TLS ALPN IDs may be registered, you would have to create an API where 
> the caller would have to supply the *input* (from application to TLS 
> implementation) as an array-of-blobs, i.e. explicit length fields
> A concatenated flat-string representation would be *MUCH* simpler and 
> nicer at the API level.

even in C like languages you just need memory pointer and a length value, I wouldn't call that, compared to just memory pointer, to be "MUCH" simpler

the first makes buffer overruns impossible - something C like languages could use more of

In some languages, like Python, you can't even have a byte array of indefinite length, making the embedded nulls a complete non-issue
> > If anything, the RFC could be updated to explicitly state that 
> > implementations MUST be able to handle the case where the IDs 
> > include null bytes.
> That would be insane.

So current RFC is insane...?

The above is just implicit, not explicit.
> If anything, an implementation receiving a ALPN ID with embedded NUL 
> characters should drop and ignore that bogus ALPN ID.
> > But this is the case for basically all fields both in TLS and X509...
> That applies only to fields with unreasonable definitions.
> Look at the TLS Server Name Indication extension:
> this has a reasonable definition for the "host_name(0)" is limited to 
> "fully qualified DNS hostname", which means that not just embedded 
> NULs are prohibited (and can be immediately dropped and ignored by the 
> TLS ClientHello PDU parser), but also "host_name(0)" > 255 chars and 
> there are several other constraints on DNS hostnames.

that's just in relation to host_name, not to SNI or TLS in general

> Robust and conservative design means that you check and skip invalid 
> data as early as possible, to limit the attack surface.  With how TLS 
> ALPN is currently defined, you can *ALWAYS* target the application on 
> top of TLS with attacks, because the TLS implementation is not 
> currently allowed to weed out obvious crap right away.

It's true, it exposes the app on top.

On the other hand, the values already passed between peers are non null terminated, so the API has to support non-null terminated strings anyway.

...please tell me you're not null terminating the ID before passing them to application....
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic