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

From: [email-masked] (Martin Rex)
Date: Wed, 1 Jul 2015 18:18:51 +0200 (CEST)

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jul 2015 16:33:53 +0000

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

---

From: Andrei Popov <[email-masked]>
Date: Wed, 1 Jul 2015 17:02:02 +0000

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:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Wednesday, July 1, 2015 9:34 AM
To: [email-masked]
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:

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

---

From: [email-masked] (Martin Rex)
Date: Fri, 3 Jul 2015 22:48:42 +0200 (CEST)

Andrei Popov wrote:
>
> 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.

You're oversimplifying the problem.

Recall the specifics of the design-flaw in rfc7301:

and then look at the data that rfc5077 proposes to carry along in
session_tickets -- there is *NO* pointer to the server certificate
that was used to establish this session:

   https://tools.ietf.org/html/rfc5077#page-11

      struct {
          ProtocolVersion protocol_version;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          opaque master_secret[48];
          ClientIdentity client_identity;
          uint32 timestamp;
      } StatePlaintext;

      enum {
         anonymous(0),
         certificate_based(1),
         psk(2)
     } ClientAuthenticationType;

      struct {
          ClientAuthenticationType client_authentication_type;
          select (ClientAuthenticationType) {
              case anonymous: struct {};
              case certificate_based:
                  ASN.1Cert certificate_list<0..2^24-1>;
              case psk:
                  opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
          };
       } ClientIdentity;

So rfc7301 + rfc5077 + application-specific certificates is a pig
that can not fly.

Btw. there is also a problem for use of TLS extension SNI
in combination with rfc5077 -- a server using rfc5077 as suggested will
be unable to prevent "virtual host confusion"

   https://bh.ht.vc/vhost_confusion.pdf

and will also be unable to properly implement the checks that rfc6066
specifies for ression resumption when TLS extension SNI is used.

> 
> To me, these are implementation details, and probably not something a
> mainstream implementation will support.

Nope, these are design characteristics (or failures) of the spec.
SSL session cache management and session resumption is an area that
has been underspecified in SSL&TLS from the beginning, and the contents
of rfc5077 suggests to me, that the amount of folks (and implementors)
who understand the consequences for caching, when a server has more than
one server certificate on his hands, might be rather small.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 4 Jul 2015 06:07:33 +0000

> So rfc7301 + rfc5077 + application-specific certificates is a pig

Well, firstly there is no requirement to structure session tickets
exactly as indicated.  They are encrypted, and the server can put
anything it wants in them.

Secondly, just like clients can implement "split" caches (use more
cache lookup attributes than just the transport endpoint), so can
servers.  The server can add a context id into the session ticket,
and only resume sessions that match that context id.

> specifies for ression resumption when TLS extension SNI is used.

Since session ticket content is a private matter for the server,
the standard does not preclude implementations that apply all the
relevant checks.  When I write code in this space, I tend to put
more of the responsibility for avoiding virtual host confusion on
the client.

> one server certificate on his hands, might be rather small.

Documenting the care due in more detail sounds like a reasonable idea.

-- 
	Viktor.