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

[Hubert Kario <[e-mail]>]

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

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