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

[Andrei Popov <[e-mail]>]

I agree with Victor that there is no conflict. If the server chooses to offer different certificates for different application protocols, such server needs to consider the negotiated ALPN ID while making the resumption decision.

And yes, if the same client alternates between different application protocols, such client can be optimized by caching session state per negotiated application protocol ID.

To me, these are implementation details, and probably not something a mainstream implementation will support. But perhaps a better-written RFC would have included this implementation guidance. I'll try to do better next time:).

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Viktor Dukhovni
Sent: Wednesday, July 1, 2015 9:34 AM
To: [e-mail]
Subject: Re: [TLS] RFC7301 ALPN conflicting objectives about app-specific server certificates

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.

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