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

Watson Ladd <watsonbladd@gmail.com> Tue, 14 April 2015 18:19 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58B71A870D for <tls@ietfa.amsl.com>; Tue, 14 Apr 2015 11:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geHOnABq24Tt for <tls@ietfa.amsl.com>; Tue, 14 Apr 2015 11:19:49 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC111A86FC for <tls@ietf.org>; Tue, 14 Apr 2015 11:19:49 -0700 (PDT)
Received: by wgso17 with SMTP id o17so21541487wgs.1 for <tls@ietf.org>; Tue, 14 Apr 2015 11:19:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2+Hv+YuonoPl+HuI8Ahkc8eO2vTy7nVOLsdRCPtwSeM=; b=GBAXAIWHAfH6hvz/oCstq8BcZCQqVM2nklyuHV0P8072kGjkQmg9QtoJZSk4EXKMwW 5t7I/KJ9k/qI/Dj764LIPrVH5vKBMJo2oLqlx2tbzDv61ZcG8Uwo/4MSP+kEZSSonGdA xQn2VqQYcXd8oAamLs94tuiiAOwHmq6uOP+1Zw02Dt06Vo5uJxaF6PiVPOiiaQFcPZ6R j+rAb5gOg4SgvoXUbtutP1C02MR8gUlWxJkIDUMrc80IXOhcanhb8GgrtNBl7I3KPTnr Ci1E8MQ8ITfWgXwWQpK9wkN9PWiW8lQ9S/lwtpt/dM4Jey310/D8/mAIp9+VBwTj6Odj zb/g==
MIME-Version: 1.0
X-Received: by 10.180.82.97 with SMTP id h1mr21784735wiy.26.1429035587842; Tue, 14 Apr 2015 11:19:47 -0700 (PDT)
Received: by 10.194.136.233 with HTTP; Tue, 14 Apr 2015 11:19:47 -0700 (PDT)
Received: by 10.194.136.233 with HTTP; Tue, 14 Apr 2015 11:19:47 -0700 (PDT)
In-Reply-To: <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com>
References: <20150413223049.63EE81B281@ld9781.wdf.sap.corp> <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com>
Date: Tue, 14 Apr 2015 11:19:47 -0700
Message-ID: <CACsn0cmxKP3pH62B5Y_QfcAkjQXD8x4FOarg7EiQOpGKVSaLJw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary=f46d0442673095b9c10513b3465f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ff9i5T9m1-MA89LvcD7JWxvWVMg>
Cc: tls@ietf.org
Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 18:19:51 -0000

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
>