Subject: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates

From: [email-masked] (Martin Rex)
Date: Tue, 30 Jun 2015 22:26:13 +0200 (CEST)

I'm currently implementing support for ALPN in our middlware,
and I'm wondering how to account for ALPN in the client side session caching
management, because rfc7301 describes two mutually exclusive objectives
and the ALPN protocol does not provide a means for the server to
disambiguate the desired semantics in the ServerHello response.

rfc7301,
   https://tools.ietf.org/html/rfc7301#section-1

Section 1. last sentence of paragraph 2 (end of page 2):

                                           Further, it would be
   advantageous to allow certificate selection based on the negotiated
   application protocol.
 
Section 1, last sentence of paragraph 4 (last paragraph):

                         The application protocol negotiation can thus
   be accomplished within the TLS handshake, without adding network
   round-trips, and allows the server to associate a different
   certificate with each application protocol, if desired.

is in conflict with

Section 3.1, last paragraph
   https://tools.ietf.org/html/rfc7301#page-5

   Unlike many other TLS extensions, this extension does not establish
   properties of the session, only of the connection.  When session
   resumption or session tickets [RFC5077] are used, the previous
   contents of this extension are irrelevant, and only the values in the
   new handshake messages are considered.

Currently, my client-side session cache management, and the decision whether
to propose a TLS session to the server for resumption, is based on a match
of the application supplied "target name" which is usually an fqdn hostname,
but could also be an abbreviated hostname or an IP address.

When the server does not resume the proposed session, and performs a
full handshake instead, my client purges the previous cached session and
adds the newly established session to the client-side session cache
instead.

If the server uses distict server certificates per application protocol
and properly(!!) performs a full handshake if the server certificate
does not fit the requested application protocol, then alternating
requests with two different protocols to the same server will result
in constant full TLS handshakes.

But what can also easily happen, is that the server is inappropriately
sharing the server-side session cache an incorrectly resuming sessions
associated with the wrong server certificate (a different certificate
than what the server would select if it would perform a full TLS handshake),
and if the different server certificate attributes are relevant to the
application protocol, then this would result in random client-side
errors (failed server certificate validation) when there is already
a session for the _other_ app in the client-side session cache.

I've seen incorrect server-side session cache pooling before, e.g.
a few years ago between docs.google.com and www.google.com.

Essentially, I believe that tagging of the session with the ALPN
negotiated protocol to result in more "predictable" behaviour, because
it will not interfere with client-side session cache management
and not result in occasional confusion should other server implementors
ever make their servers use different server certificates for
different ALPN-negotiated protocols.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Jun 2015 21:31:24 +0000

Hi Martin,

> If the server uses distict server certificates per application protocol and properly(!!) performs a full handshake if the server certificate does not fit the requested application protocol, then alternating requests with two different protocols to the same server will result in constant full TLS handshakes.

Yes, if a client negotiates a different application protocol on a subsequent connection, the server may reject resumption (which the server can always do anyway, regardless of ALPN).
 
> But what can also easily happen, is that the server is inappropriately sharing the server-side session cache an incorrectly resuming sessions associated with the wrong server certificate (a different certificate than what the server would select if it would perform a full TLS handshake), ...

This would be a server bug indeed.

> Essentially, I believe that tagging of the session with the ALPN negotiated protocol to result in more "predictable" behaviour, because it will not interfere with client-side session cache management and not result in occasional confusion should other server implementors ever make their servers use different server certificates for different ALPN-negotiated protocols.

Can you describe how such tagging would work in more detail?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Tuesday, June 30, 2015 1:26 PM
To: [email-masked]
Subject: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates

I'm currently implementing support for ALPN in our middlware, and I'm wondering how to account for ALPN in the client side session caching management, because rfc7301 describes two mutually exclusive objectives and the ALPN protocol does not provide a means for the server to disambiguate the desired semantics in the ServerHello response.

rfc7301,

                                           Further, it would be

is in conflict with

Currently, my client-side session cache management, and the decision whether to propose a TLS session to the server for resumption, is based on a match of the application supplied "target name" which is usually an fqdn hostname, but could also be an abbreviated hostname or an IP address.

When the server does not resume the proposed session, and performs a full handshake instead, my client purges the previous cached session and adds the newly established session to the client-side session cache instead.

If the server uses distict server certificates per application protocol and properly(!!) performs a full handshake if the server certificate does not fit the requested application protocol, then alternating requests with two different protocols to the same server will result in constant full TLS handshakes.

But what can also easily happen, is that the server is inappropriately sharing the server-side session cache an incorrectly resuming sessions associated with the wrong server certificate (a different certificate than what the server would select if it would perform a full TLS handshake), and if the different server certificate attributes are relevant to the application protocol, then this would result in random client-side errors (failed server certificate validation) when there is already a session for the _other_ app in the client-side session cache.

Essentially, I believe that tagging of the session with the ALPN negotiated protocol to result in more "predictable" behaviour, because it will not interfere with client-side session cache management and not result in occasional confusion should other server implementors ever make their servers use different server certificates for different ALPN-negotiated protocols.

-Martin

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 Jul 2015 01:00:42 +0200 (CEST)

Andrei Popov wrote:
> Yes, if a client negotiates a different application protocol on a
> subsequent connection, the server may reject resumption (which the
> server can always do anyway, regardless of ALPN).

Correct, the server may decide for a full handshake for a number of reasons.
But in general, I want TLS session caching to work and expect to see
a session resumption vs. full handshake rate of >> 10:1 on healthy servers.

>> than what the server would select if it would perform a full TLS
>>  handshake), ...
> 

No, not right now.  It would be a server implementing a defective
specification as written, due to the last paragraph in section 3.1
of rfc7301.

>> negotiated protocol to result in more "predictable" behaviour,
>> because it will not interfere with client-side session cache
>> management and not result in occasional confusion should other
>> server implementors ever make their servers use different server
>> certificates for different ALPN-negotiated protocols.
> 

For the client, I will memorize the app-requested ALPN list in
the client-side session cache and attempt resumption only when
the application supplies the same ALPN list.

For the server, two possible approaches are conceivable.

(1) an extension specific approach, where the server includes the
    chosen app protocol in the server-side session cache and
    checks for a match on attempted resumption.

(2) a generally robust approach that solves this and all related issues
    once and for all (but may not integrate easily with certain
    protocol stack implementations...)

    The server processes ClientHello always in the same fashion as
    it would do for a full TLS handshake, and only if it done with
    deciding all negotiation, it checks for a proposal to resume an
    old session.  If there is a resumption proposal, the server
    compares the attributes of the newly negotiated parameters
    with that of the resumed session, and if the properties
    differ (in particular, if the new handshake would use a different
    server certificate than the cached session had used), the
    server will perform a full handshake instead of a session resume
    and the resulting server behaviour will bear the lowest risk of
    surprises (i.e. the session caching only results in speedup, but
    not in sessions with different properties or different identites).

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 30 Jun 2015 23:53:40 +0000

>    new handshake messages are considered.

I don't think there's a conflict here.  All that's said is that
ALPN is not a session property, and its value for a previous
connection is not directly relevant for a new connection.  Each
connection signals its own ALPN value.

Now to the extent that a new connection elects a different protocol
and thus a different server certificate chain, or the server's
configuration has changed and the same ALPN protocol is now associated
with a new certificate chain, the server needs to perform a full
handshake, so that the client sees the correct certificate chain.

> but could also be an abbreviated hostname or an IP address.

Postfix has had solved a similar issue some time ago, because
multiple SMTP destination domains can use the same MX host, but
the sending MTA administrator TLS policy may differ between domains
and these domains might use distinct "transports" (instances of
SMTP delivery channels, roughly analogous to a Sendmail "mailer"),
where each transport has different trust-anchors or other relevant
TLS settings.

Therefore, the client cache is indexed by multiple properties that
extract the enough detail from the security policy to make sure we
are reaching the right server at the right security level.  The
relevant attributes are:

    * Postfix "transport name".  Different transports
      have potentially very different base TLS settings, and it is
      simplest to not mix session caches accross "transports"

    * Nexthop domain (with port), MX hostname and target IP address.
      Some MX hosts that appear to be a single multi-homed host are
      in fact multiple hosts with separate caches, so each IP address
      gets a different parallel cache.

    * The EHLO name of the remote SMTP server, this detects split
      caches (multiple SMTP servers) behind a load balancer.

	C: EHLO client-name
	S: 250-<server-name>
	   ...
	   250 STARTTLS

      Google's pool of MX hosts at any given IP address, has a
      shared session cache, and a common EHLO name, so session
      caching works well across the load balancer.  Some providers
      have shared caches, but fail to return a common HELO name,
      and the client cache is then not nearly as effective.

    * ...

> different ALPN-negotiated protocols.

So, yes include all TLS security-relevant attributes in some manner
in the client cache lookup key to avoid mixing cached sessions with
incompatible security requirements.

-- 
	Viktor.