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

Hubert Kario <> Wed, 15 April 2015 09:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C0271B339A for <>; Wed, 15 Apr 2015 02:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xh2G-RfJqTmm for <>; Wed, 15 Apr 2015 02:08:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D90441B339B for <>; Wed, 15 Apr 2015 02:08:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 2CC36330488; Wed, 15 Apr 2015 09:08:01 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t3F97w2M031601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2015 05:08:00 -0400
From: Hubert Kario <>
Date: Wed, 15 Apr 2015 11:07:51 +0200
Message-ID: <>
User-Agent: KMail/4.14.4 (Linux/3.19.3-100.fc20.x86_64; KDE/4.14.6; x86_64; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4865205.j5dlBgs6D6"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
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 09:08:04 -0000

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 

> 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 
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic