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

[[e-mail] (Martin Rex)]

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.

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.


> 
> 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.

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:

  https://tools.ietf.org/html/rfc6066#section-3

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.


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. 


-Martin