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

On Apr 14, 2015 11:04 AM, "Hubert Kario" <hkario@redhat.com> wrote:
>
> 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...

And this has been a continuous source of pain, leading to exploits. Moreso
on the X.509 side.

Sincerely,
Watson Ladd
> --
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>