[TLS] RFC 5077 (was Re: draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted)

[Michael D'Errico <[e-mail]>]

Brian Smith wrote:
> .... Note that this is how RFC50[77] works (you 
> have to infer what the server is saying based on what handshake messages 
> it skips; for example, if the server doesn't send a Certificate right 
> after its ServerHello then you have to infer that it's doing a 
> resumption based on the given ticket).

While that method works, an easier method is for the client to include a
non-empty session ID in its ClientHello when attempting to resume a session
based on a session ticket.  If the server does resume the session, then it
returns the client-generated session ID.  From RFC 5077:

    When presenting a ticket, the client MAY generate and include a
    Session ID in the TLS ClientHello.  If the server accepts the ticket
    and the Session ID is not empty, then it MUST respond with the same
    Session ID present in the ClientHello.  This allows the client to
    easily differentiate when the server is resuming a session from when
    it is falling back to a full handshake.  Since the client generates a
    Session ID, the server MUST NOT rely upon the Session ID having a
    particular value when validating the ticket.  If a ticket is
    presented by the client, the server MUST NOT attempt to use the
    Session ID in the ClientHello for stateful session resumption.
    Alternatively, the client MAY include an empty Session ID in the
    ClientHello.  In this case, the client ignores the Session ID sent in
    the ServerHello and determines if the server is resuming a session by
    the subsequent handshake messages.

Mike