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

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> On Tue, Jun 30, 2015 at 10:26:13PM +0200, Martin Rex wrote:
>> 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.


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.

This is in direct conflict with the idea of selecting protocol-specific
certificates through ALPN and describing ALPN as connection-specific
rather than session-specific.


Another issue is renegotiation:  it makes little sense to allow
ALPN to change the negotiated protocol during the renegotiation handshake,
because this would cause extreme complexity and all kinds of problems,
in particular because of two issues:

  - rfc5746 urges TLS implementations to not allow change of
    (server)certificate during renegotiation without an explicit
    opt-in by the application, because most application will not
    be able to properly deal with this--most even don't know or
    realize that it happens/happend, such as HTTP-based apps
    on a blocking OpenSSL-Style interface (SSL_read()) that
    are forced through a renegotiation by the server (who
    is asking for a client certificate with renegotiation),
    and do not actually realize that there was a renegotiation
    during the blocking SSL_read() operation while they were
    waiting for a response.

  - how would the change in the negotiated protocol affect the
    application layer protocol.

    e.g. what would it mean if the client offers http/1.1 and h2
    through ALPN on both handshakes (initial and renegotiation)
    and the server would pick "http/1.1" on the inital handshake
    and "h2" on the renegotiation for "using renego to request
    a client cert after having seen the request" for the
    application layer protocol semantics.  Will a client app
    that enables ALPN suddenly have to check the "current" ALPN
    protocol for every single SSL_read() operation that returns
    app data, because there may have been a transparent renegotation
    under the cover and the protocol may have changed?


-Martin
    
  - How would a change in the ALPN protocol







> 
> 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.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls