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

[Viktor Dukhovni <[e-mail]>]

On Tue, Jun 30, 2015 at 10:26:13PM +0200, Martin Rex wrote:

> 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.

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.

> 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.

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.

    * ...

> 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.

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.