Re: [TLS] Encrypting ALPN and other unused extensions

mrex@sap.com (Martin Rex) Fri, 25 April 2014 17:36 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 6F9B01A068B for <tls@ietfa.amsl.com>; Fri, 25 Apr 2014 10:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 S-aqGNRBiYoj for <tls@ietfa.amsl.com>; Fri, 25 Apr 2014 10:36:18 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D21A0229 for <tls@ietf.org>; Fri, 25 Apr 2014 10:36:17 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3PHa8la018393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Apr 2014 19:36:09 +0200 (MEST)
In-Reply-To: <535A8CED.7030805@pobox.com>
To: Michael D'Errico <mike-list@pobox.com>
Date: Fri, 25 Apr 2014 19:36:08 +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: <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/INRDfyrvtxrAjlfnfYn4phBcF8s
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypting ALPN and other unused extensions
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: Fri, 25 Apr 2014 17:36:20 -0000

Michael D'Errico wrote:
> Watson Ladd wrote:
> > 
> > Some extensions aren't used by the TLS layer, like ALPN.
> 
> ALPN is used by the TLS layer.  The requested protocol is
> one of several inputs to a server's certificate selection
> algorithm, along with the SNI.

I agree that the information is conveyed within the TLS protocol,
so the TLS stack may need to be able to pass this information
between TLS stack an application, but there is no need that the
TLS stack uses this information for anything.

With TLS extension SNI, the server side TLS stack might even completely
ignore the information, i.e. not implement it.

A Hosting provider could set up an SNI-aware load balancer and
dispatch/NAT incoming TLS sessions in opaque fashion to individual
TLS servers, and the individual server can just ignore the contents
of TLS extension SNI (or may not even implement it), and virtual
hosting would still work just fine.  There would be no server name
confirmantion in ServerHello extensions, but that is a quite
irrelevant part of TLS extension SNI.


-Martin