Re: [TLS] WGLC: draft-ietf-tls-session-hash

[Henrik Grubbström <[e-mail]>]

On Fri, Jan 16, 2015 at 12:29 AM, Eric Rescorla <[e-mail]> wrote:
>
> On Thu, Jan 15, 2015 at 3:21 PM, Martin Thomson <[e-mail]>
> wrote:
>>
>> On 15 January 2015 at 14:51, Eric Rescorla <[e-mail]> wrote:
>> > For sessions negotiated without EMS:
>> > - SHOULD not resume
>> > - MUST not resume sessions if the client offers EMS in the resumption
>> >   (and therefore SHOULD do a complete negotiation).
>> >
>> > For sessions negotiated with EMS:
>> > - The client ??? offer EMS
>> > - The server MUST NOT echo it?
>>
>> Just to be clear, this latter part is...when renegotiating.
>
> When resuming, right?

Maybe something like the following should be added in TLS 1.3?

A session MUST only be resumed if the server would create an
equivalent session (including the same server certificate and version
of TLS) on resumption failure. On resumption failure the session_id
provided in the ClientHello MUST be invalidated.

Such a rule would ensure that extensions like server_name,
max_fragment_length, truncated_hmac, encrypt_then_mac and
extended_master_secret (where relevant) are kept in the resumption
ClientHello, and that the connection won't be downgraded on resumption
failure.

>> My preference is: if the session had EMS, when renegotiating:
>>  - the client MUST offer the extension, and
>>  - the server MUST fail the handshake (new alert needed?) if the
>> extension isn't present.
>>
>> That means no resumption, OR fallback to the complete handshake.
>>
>> I think that I'd prefer to have the server echo the extension in this
>> case too.  It's a few bytes effectively wasted, but it makes
>> everything nice and symmetrical.  Clients says "I want EMS" and server
>> says "you got EMS".

Sounds good to me.

/grubba

-- 
Henrik Grubbström                                       [e-mail]
Roxen Internet Software AB                              [e-mail]