Subject: Re: [TLS] RFC 7366 and resumption

From: Peter Gutmann <[email-masked]>
Date: Wed, 5 Nov 2014 19:33:23 +0000

Manuel Pégourié-Gonnard <[email-masked]> 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.

Peter.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 05 Nov 2014 21:57:45 +0100

> if present in Client Hello.
Ok, thanks for the confirmation!

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Wed, 5 Nov 2014 23:44:37 +0100 (CET)

Manuel Pégourié-Gonnard wrote:
> Peter Gutmann wrote:
>> Yes, it just follows standard practice from RFC 5246,
>> so the server ignores it if present in Client Hello.
>

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

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 06 Nov 2014 01:08:55 +0100

> is lacking the EtM extension looks like a bad idea to me.
I'm not sure if we're talking about the same thing here. Do we agree that a
session that was started using EtM will still be using EtM on resumption,
regardless of whether the client sent the extension the second time (and whether
the server replied with the extension)? If so, I fail to understand what is
bothers you.

> the session tickets may have to be synchronously updated with a flag
I don't think the behaviour described in RFC 5246 is supposed to apply to RFC
5077, since the former states that

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.

and RFC 5077 indeed describes explicitly how the extension is supposed to be
used both for full handshake and resumed handshakes.

> [...]
> the latter (*>) paragraph.

I noticed that too. I guess it's a leftover from the previous version, since
Appendix A mentions changes regarding SNI use on resumption since RFC 4366. I
would assume the author forgot to change the paragraphs you quote: they should
now say something like "all the extensions defined in this document except SNI".

> properties of the resulting security context.

Both RFC 5246 and 6066 say that the client SHOULD include the extensions when
attempting to resume a session, since they can't know if resumption or a full
handshake will follow. If you're arguing that this SHOULD should be a MUST, I
think I'm sympathetic with your argument.

Manuel.