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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jul 01, 2015 at 06:18:51PM +0200, Martin Rex wrote:

> >>    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.
> 
> There is a very clear conflict here.
> 
> A TLS session resume skips the exchange of credentials&identities
> (such as certificates), so as a result of a session resumption
> the session will have the _cached_ certificates from the original
> full TLS handshake as session attributes.

And yet it is not a conflict.  The specification says ALPN is
per-connection.  Since certificates are per-session, either the
client or the server need to do the right thing and not re-use
sessions that are not compatible with the requested ALPN.

Clients can try to maximize session re-use and leave the logic up
to the server (to perform a new handshake when the initial ALPN is
associated with a different server identity), or clients can maximize
correctness in the face of sloppily implemented servers and avoid
reuse of sessions for a different ALPN value.

So indeed most clients should create one session per ALPN value,
thus turning ALPN into a session property.  Clients that can
reasonably expect correct server logic might leave it up to the
server to decide whether to create a new session, or allow re-use,
because both the new and the old ALPN value map to the same server
identity.

-- 
	Viktor.