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

[Hubert Kario <[e-mail]>]

On Tuesday 14 April 2015 00:30:49 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.

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.

But this is the case for basically all fields both in TLS and X509...
-- 
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