IETF Logo Mail Archive

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

mrex@sap.com (Martin Rex) Mon, 13 April 2015 22:30 UTC

Return-Path: <mrex@sap.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 0C7BC1ACE82 for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 15:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 USImt0rg3Q-V for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 15:30:52 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26D91ACE88 for <tls@ietf.org>; Mon, 13 Apr 2015 15:30:51 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 779532ABE4; Tue, 14 Apr 2015 00:30:49 +0200 (CEST)
X-purgate-ID: 152705::1428964249-00003099-693B1795/0/0
X-purgate-size: 827
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6C3244359F; Tue, 14 Apr 2015 00:30:49 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 63EE81B281; Tue, 14 Apr 2015 00:30:49 +0200 (CEST)
In-Reply-To: <BN3PR0301MB1250704298FBDE17EC56BCDD8CE70@BN3PR0301MB1250.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Tue, 14 Apr 2015 00:30:49 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150413223049.63EE81B281@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_DjrS_DxDnjxymanRYY0QdBqB-U>
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
Reply-To: mrex@sap.com
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: Mon, 13 Apr 2015 22:30:54 -0000

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.

-Martin

v2.23.0 | Report a Bug | By Email