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

Martin Thomson <martin.thomson@gmail.com> Wed, 15 April 2015 18:38 UTC

Return-Path: <martin.thomson@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 3B3D61A19F4 for <tls@ietfa.amsl.com>; Wed, 15 Apr 2015 11:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 xU3odOH-1X9Q for <tls@ietfa.amsl.com>; Wed, 15 Apr 2015 11:38:11 -0700 (PDT)
Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 D04E71A19E9 for <tls@ietf.org>; Wed, 15 Apr 2015 11:38:10 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so18520423vnb.5 for <tls@ietf.org>; Wed, 15 Apr 2015 11:38:10 -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:content-transfer-encoding; bh=/M5xKXs78/TaU87s5qTuKCp04iuw4d+VyUV0rEEo2rs=; b=LDz8SAcvbCMbIqr7usvhln8aAKTvFjNkybCiD4cZHvEn1vaizChQETEmxnm9WrmthU LMWcVRRqqAXAN6wU5qqGF0CMmEBJpITIEtudw3gvvYSTXDq9qnnmGKhNtPiPpEpBw2pq 90aoWNi7PVzH+SXxQiypAHWTOMIC9cl5KnjbDi2h0AxbL1WX0zXamSrXW/HNHBHKWwq+ mT3utdUsr2cwzTslYjXoe5wa0b6OLcV8vs1rTL1P0GWGnuySY3r4X7gufcN361ATSevx JFdsIwTi3C0ViVPGPsfRf64PatMoOSY7RJFWCmlyfOlCbNQZkyQaTcHWiYOsqRLEmJ3B AuvQ==
MIME-Version: 1.0
X-Received: by 10.182.39.195 with SMTP id r3mr22223992obk.44.1429123090116; Wed, 15 Apr 2015 11:38:10 -0700 (PDT)
Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 11:38:10 -0700 (PDT)
In-Reply-To: <BN3PR0301MB12509693B1F91EAA100F18958CE50@BN3PR0301MB1250.namprd03.prod.outlook.com>
References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> <BN3PR0301MB12509693B1F91EAA100F18958CE50@BN3PR0301MB1250.namprd03.prod.outlook.com>
Date: Wed, 15 Apr 2015 11:38:10 -0700
Message-ID: <CABkgnnUU5E76o9g7em57xujaKtqg5ApH=9Mtm3MHpc3uyi8G+Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SktAjHXWbmTMVIa9qLjmptfJOH8>
Cc: "tls@ietf.org" <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: Wed, 15 Apr 2015 18:38:12 -0000

On 15 April 2015 at 11:14, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> Having said that, ALPN RFC allows the use of arbitrary octet strings as ALPN IDs, so unfortunately the simple API that assumes NUL-terminated ASCII IDs is not sufficient. And of course any code that matches ALPN IDs has to perform the comparison of byte arrays rather than some form of string comparison.


Well, you *could* implement something that only took NUL-terminated
ASCII labels.  That could still work, even if it encountered junk as
long as the implementation correctly checked lengths first.  It would
only fail to work if you actually need to talk to someone who wanted
to include a crazy value.