[TLS] Questions about ALPN

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 09 April 2014 15:54 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 BC7351A03AD for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 08:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 hw_T7S-rXgdb for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 08:54:29 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 078BD1A03AA for <tls@ietf.org>; Wed, 9 Apr 2014 08:54:03 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id no9m1n0031HzFnQ5Cru3od; Wed, 09 Apr 2014 15:54:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id nru31n00L3ZTu2S3aru3dY; Wed, 09 Apr 2014 15:54:03 +0000
Message-ID: <53456D1B.1010804@alum.mit.edu>
Date: Wed, 09 Apr 2014 11:54:03 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397058843; bh=ClxOPWKtyt72dY681irhpfmcdKpeEE4rfFm6sJY4JnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Za7L6VhmUcFRvI+rLOzM0xtlyZ1K8hbP81dkS/Mbg2yLuyD2RYiyMtmxH5pPJ8yyL 4JO1lnonUStCHrMXi9GuZdXimoif33s3NHcgPf4m/mhygzoYCh/5eausIMHlTvzRtx 2EyYtnvAZR1qLU9K/V6FvLwqaUtsf9jURV/bbcfZfllC9gnE7pXGjbQzEfz1NUN8jM 0korHQiDWjscE7XffiAXe9KZRSvzz4dEMzLVLHo5Ar1PsiKqHH89puNoGeVSnqDJ+I azTIghOTB/y0D8WZp1kiQSiZajHiyNK1kDBaZVcNl5NWM1E8ZlDE7nycZd6OXZVap0 cgVf0Uy0zZz5g==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/crf6-T4wRL32olVSdEsQkTWLX0M
Subject: [TLS] Questions about ALPN
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, 09 Apr 2014 15:54:29 -0000

[Disclaimer: I'm new here - I just subscribed to this list so that I 
could discuss this point. So don't assume I have much context.]

I've been seeing suggestions here and there recently to use ALPN as a 
registry of protocols for various purposes. So I went looking to find 
out what that was. And I found draft-friedl-tls-applayerprotoneg. IIUC 
this is *the* authoritative definition of ALPN.

 From the friedl draft I understand its use in the context of TLS. I 
would like to understand if the *intended* scope of applicability is 
broader, and if so, what it is.

For instance, the draft doesn't mention DTLS. But I have found 
discussion elsewhere that says it is intended to be used for DTLS. I do 
understand that DTLS and TLS are closely related, and apparently it is 
intended that both will share the same Next Protocol Negotiation 
mechanism. And that means that each will need a registry of protocol 
names that may be used within this negotiation.

OTOH, it is far from clear that the *same* registry should be used for 
both TLS and DTLS. The two transports have significantly different 
characteristics, so that many application protocols will only work over 
one or the other. (Or if they work over both, they might arguably be 
*different* protocol variants.)

And what about using the ALPN registry for protocols that run on top of 
transports other that TLS and DTLS? Is that appropriate?

IMO at the very least the IANA Considerations section of this draft 
should be beefed up as follows:

- Specify the policy IANA is to use for deciding whether to accept
   a new registration in the ALPN registry. (You can't define a new
   registry without this.)

- Specify clearly the information that is to appear in the ALPN
   registry. IMO, in addition to the name this needs to include
   *at least* the transport protocol(s) over which the application
   layer protocol is valid.

- Specify the transport layer protocols that are valid transports
   of ALPN protocols.

- Specify the acceptable syntax of ALPN names

- Specify guidelines for when it is appropriate to add a new protocol
   to the ALPN registry. (E.g., when it is intended to be used in
   NPN negotiation in TLS and DTLS.)

Without some clarity here I fear that people will be tempted to use this 
registry for registering names of arbitrary protocols that run over 
arbitrary other protocols. (E.g., as an alternative to the IANA registry 
of SDP "proto" values.)

	Thanks,
	Paul