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

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:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Tuesday, June 30, 2015 1:26 PM
To: tls@ietf.org
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,
   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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls