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

[[e-mail] (Martin Rex)]

Andrei Popov wrote:
>> 
>> If the server uses distict server certificates per application protocol
>> and properly(!!) performs a full handshake if the server certificate
>> does not fit the requested application protocol, then alternating
>> requests with two different protocols to the same server will result
>> in constant full TLS handshakes.
> 
> Yes, if a client negotiates a different application protocol on a
> subsequent connection, the server may reject resumption (which the
> server can always do anyway, regardless of ALPN).

Correct, the server may decide for a full handshake for a number of reasons.
But in general, I want TLS session caching to work and expect to see
a session resumption vs. full handshake rate of >> 10:1 on healthy servers.


>  
>> But what can also easily happen, is that the server is inappropriately
>> sharing the server-side session cache an incorrectly resuming sessions
>> associated with the wrong server certificate (a different certificate
>> than what the server would select if it would perform a full TLS
>>  handshake), ...
> 
> This would be a server bug indeed.

No, not right now.  It would be a server implementing a defective
specification as written, due to the last paragraph in section 3.1
of rfc7301.


> 
>> 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.
> 
> Can you describe how such tagging would work in more detail?

For the client, I will memorize the app-requested ALPN list in
the client-side session cache and attempt resumption only when
the application supplies the same ALPN list.

For the server, two possible approaches are conceivable.

(1) an extension specific approach, where the server includes the
    chosen app protocol in the server-side session cache and
    checks for a match on attempted resumption.

(2) a generally robust approach that solves this and all related issues
    once and for all (but may not integrate easily with certain
    protocol stack implementations...)

    The server processes ClientHello always in the same fashion as
    it would do for a full TLS handshake, and only if it done with
    deciding all negotiation, it checks for a proposal to resume an
    old session.  If there is a resumption proposal, the server
    compares the attributes of the newly negotiated parameters
    with that of the resumed session, and if the properties
    differ (in particular, if the new handshake would use a different
    server certificate than the cached session had used), the
    server will perform a full handshake instead of a session resume
    and the resulting server behaviour will bear the lowest risk of
    surprises (i.e. the session caching only results in speedup, but
    not in sessions with different properties or different identites).


-Martin