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

[[e-mail] (Martin Rex)]

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:

   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.

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