Re: [TLS] RFC 7366 and resumption

[Manuel Pégourié-Gonnard <[e-mail]>]

On 05/11/2014 23:44, Martin Rex wrote:
> 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.
> 
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.

> 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...
> 
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.

> Btw. rfc6066 contains at least one self-inconsistency at this point:
> [...]
> 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.

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".

> 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.

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.