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

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Jul 2014 21:57:37 -0400

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.

Thoughts?  Is this something we need to specify?  Or give general advice for the processing order of extzensions?

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: [email-masked] (Martin Rex)
Date: Wed, 30 Jul 2014 07:22:43 +0200 (CEST)

> 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.
> 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
   http://tools.ietf.org/html/rfc3546#section-3.4

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.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Jul 2014 10:09:40 -0400

> Technically, interference of protocol options could arise already

Yes.  I'm trying to find out if that's a general problem we should address.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 09:22:42 -0700

On 29 July 2014 18:57, Salz, Rich <[email-masked]> wrote:
> 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.
>

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?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Jul 2014 12:29:29 -0400

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

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?

But I'm not gonna lose any sleep over it if the WG feels otherwise.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 09:42:17 -0700

> 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 shoul…

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Jul 2014 12:51:28 -0400

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

Which is what I said at the beginning :)