Re: [TLS] RFC 7366 and resumption

[[e-mail] (Martin Rex)]

Manuel Pégourié-Gonnard wrote:
> Peter Gutmann wrote:
>> Manuel Pégourié-Gonnard <[e-mail]> writes:
>> 
>>> It seems to me that RFC 7366 falls in the same category as "Most current TLS
>>> extensions" above, ie is only relevant when a session is initiated, and on
>>> resumption the server should ignore the extension and restore the state from
>>> the saved session.
>> 
>> Yes, it just follows standard practice from RFC 5246,
>> so the server ignores it if present in Client Hello.
>
> Ok, thanks for the confirmation!


Huh?  I believe such behaviour to be partially WRONG (and a bad idea).

Not returning the extension in ServerHello on resumption seems
to be current worst^Wbest practice, but resuming a session that
was originally negotiated with EtM when the resumption request
is lacking the EtM extension looks like a bad idea to me.

Btw. such behaviour means that any rfc5077-style TLS session tickets
will have to accomodate all such properties, and all servers sharing
the session tickets may have to be synchronously updated with a flag
day...


Btw. rfc6066 contains at least one self-inconsistency at this point:

rfc6066 on the bottom of page 4 reads:

*> Note also that all the extensions defined in this document are
*> relevant only when a session is initiated.  A client that requests
   session resumption does not in general know whether the server will
   accept this request, and therefore it SHOULD send the same extensions
   as it would send if it were not attempting resumption.  When a client
   includes one or more of the defined extension types in an extended
   client hello while requesting session resumption:

   -  The server name indication extension MAY be used by the server
      when deciding whether or not to resume a session as described in
      Section 3.

   -  If the resumption request is denied, the use of the extensions is
      negotiated as normal.

*> -  If, on the other hand, the older session is resumed, then the
*>    server MUST ignore the extensions and send a server hello
*>    containing none of the extension types.  In this case, the
*>    functionality of these extensions negotiated during the original
*>    session initiation is applied to the resumed session.


And the definition of the Server Name Indication extension, that is
part of this RFC 6066, explicitly contradicts the first sentence of
the latter (*>) paragraph.  But agrees with the second sentence:

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.  When resuming a session, the server MUST
   NOT include a server_name extension in the server hello.


Personally, I would consider it much more logical for the EtM spec
when it would "perform a full handshake instead" if a client proposes
to resume a session that was originally established with EtM, but
fails to include the EtM extension in the resumption request.

This latter behaviour follows the "principle of least surprise".
Whether the server has already flushed the session from the server-side
cache that the client proposes for resumption should not affect the
properties of the resulting security context.  Otherwise the behaviour
will become strangely non-deterministic, and the only part of one's
software that should exhibit non-deterministic behaviour are those
few functions that are officially labelled as random number generators.


-Martin