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

Martin Thomson <martin.thomson@gmail.com> Wed, 30 July 2014 16:22 UTC

MIME-Version: 1.0
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com>
Date: Wed, 30 Jul 2014 09:22:42 -0700
Message-ID: <CABkgnnW2x9v36GkwSic6+0B=S9ZxD9X6MLq3Upqk8XqyXMOtjA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RG3vGon0bBSEkgwJcOXdrMzpWrE
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] SNI and ALPN -- which firsr?
Precedence: list

On 29 July 2014 18:57, Salz, Rich <rsalz@akamai.com> wrote:
> Is there a fixed order for processing a hello that has both ALPN and SNI?
>
> 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.

I don't think that order of processing needs to be fixed, or the same
for different deployments.  I can imagine that some deployments might
want to have a table that uses both inputs simultaneously.  Specifying
a fixed processing order removes some flexibility.

Is there a particular reason that a fixed order would be of an advantage?

[TLS] SNI and ALPN -- which firsr? Salz, Rich
Re: [TLS] SNI and ALPN -- which first? Martin Rex
Re: [TLS] SNI and ALPN -- which first? Salz, Rich
Re: [TLS] SNI and ALPN -- which firsr? Martin Thomson
Re: [TLS] SNI and ALPN -- which firsr? Salz, Rich
Re: [TLS] SNI and ALPN -- which firsr? Martin Thomson
Re: [TLS] SNI and ALPN -- which firsr? Salz, Rich