Re: [TLS] SNI and ALPN -- which first? (Martin Rex) Wed, 30 July 2014 05:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C7EC1B2815 for <>; Tue, 29 Jul 2014 22:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7b-__Z23QYDp for <>; Tue, 29 Jul 2014 22:22:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 660BA1A0AFA for <>; Tue, 29 Jul 2014 22:22:47 -0700 (PDT)
Received: from by (26) with ESMTP id s6U5MhSP003574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 07:22:43 +0200 (MEST)
In-Reply-To: <>
To: "Salz, Rich" <>
Date: Wed, 30 Jul 2014 07:22:43 +0200 (CEST)
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: <>
From: (Martin Rex)
X-SAP: out
Cc: " \(\)" <>
Subject: Re: [TLS] SNI and ALPN -- which first?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jul 2014 05:22:50 -0000

Salz, Rich wrote:
> Is there a fixed order for processing a hello that has both ALPN and SNI?

No, I don't think so.

> For example, if you do ALPN first, then the SNI might end up "pointing to"
> a client with weaker ciphers than, say HTTP/2 allows.
> On the other hand, I can see the case that the SNI is protocol-specific,
> so you should do ALPN first.
> Thoughts?  Is this something we need to specify?
> Or give general advice for the processing order of extensions?

Technically, interference of protocol options could arise already
between cipher suites and server certificates selected through SNI,
or between Elliptic curves and server certificates selected through SNI,
or a client's "Trusted CA" TLS extension

What you may want to offer depends on what you can describe and make
configurable in a fashion that
   - your customers/consumers still understand the configuration
   - your clients/users still understand your server's behaviour
   - your support folks still have a chance to figure out what's going on
     if things don't work the way which users or admins expected it to.