Re: [TLS] SNI and ALPN -- which firsr?

Martin Thomson <martin.thomson@gmail.com> Wed, 30 July 2014 16:42 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 82D181A0242 for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:42:22 -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 nXNBszDzJCPE for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 09:42:18 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891B41A0197 for <tls@ietf.org>; Wed, 30 Jul 2014 09:42:18 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hi2so7860567wib.4 for <tls@ietf.org>; Wed, 30 Jul 2014 09:42:17 -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=1zafjxogWOrGvLsPlzlGeCLKSe4815s9qet41k7+OU4=; b=zk2lrKJxxBBN6wmJjq5wj9omBvu+ND1iXc3BNYxNGdBMpzyRXw1FXFPTuVGVzwSxA0 kgUhGFf8diRl04scZnwBkUzE0Y9VqdI+bYKXExxkBAzO55g7sqpKB6FyBE5PaNDhA5tf e+GllX7P1yIQUumdjdo6kLvFcWl0w30p2aqtTnAsqDeYb4Z0j6BuU44xQN35wVV+KZAh 21dIX0VZ/JoPxGdxR/uDupMmV8LKg21lQKCR01dG/up7AUUl/hc+wy4G+qkk6DRNB19n bTR4bNbqZmcuCK7ZVxYlss6z8bJqykt59HEGpbXbmIkTOPs3XQVWX2JQgnNZLFCtnPUL AytQ==
MIME-Version: 1.0
X-Received: by 10.180.104.42 with SMTP id gb10mr8398451wib.65.1406738537119; Wed, 30 Jul 2014 09:42:17 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 09:42:17 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> <CABkgnnW2x9v36GkwSic6+0B=S9ZxD9X6MLq3Upqk8XqyXMOtjA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com>
Date: Wed, 30 Jul 2014 09:42:17 -0700
Message-ID: <CABkgnnUL8UDdFh5KEjgA6+2fv3N0YJ0C235ZQ91cgwhqF2R=ZQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bF9fVSa-mrbJ6a-CNSohhnEnSn4
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] SNI and ALPN -- which firsr?
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, 30 Jul 2014 16:42:22 -0000

On 30 July 2014 09:29, Salz, Rich <rsalz@akamai.com> wrote:
> A fixed order of precedence is generally a good thing.  Among other things, it forces you to think about  the interactions and encourages consistent behavior.  For example, which do YOU think should be done first?

I can imagine several different, but equally valid deployment
configurations that suggest either.

You could divide back-end servers by protocol.  Each of them can
handle the complete set of names that are served (images.example.com,
www.example.com, accounts.example.com, etc...), but one pool does
HTTP/1.1 and the other does HTTP/2.  In that case, you would route on
ALPN.  This is even more important if we start seeing clients connect
with an "xmpp" token rather than an "h2" or "http/1.1" token.  This
might help with the very different connection management profiles of
different protocol versions.

An alternative, which I'd consider preferable in the HTTP case,
divides back-end machines by function (static.example.com,
www.example.com, billing.example.com) and all hosts can handle all the
application protocols.

Or you might combine these.  For instance, xmpp.example.com is a host
that responds to SNI for that name, or an "xmpp" ALPN for an
unqualified example.com.  Other hosts could use any of the other
configurations.

Where order of processing becomes relevant is where there are errors
generated by both extensions.  Which error do you report?  Honestly,
I'd rather not mandate anything in a standard here, though I might
appreciate that determinism is valuable when developing a test plan
for a product.