tree 4dd68f3f018cffaec9ab135345a9f4c7e10e20c3
parent b0eef0aee9a9c52005a7a8421f0d1b2dc9f6b99e
author Adam Langley <alangley@gmail.com> 1433267435 -0700
committer Adam Langley <agl@google.com> 1433369150 +0000

Tighten up EMS resumption behaviour.

The client and server both have to decide on behaviour when resuming a
session where the EMS state of the session doesn't match the EMS state
as exchanged in the handshake.

                        Original handshake
      |  No                                         Yes
------+--------------------------------------------------------------
      |
R     |  Server: ok [1]                     Server: abort [3]
e  No |  Client: ok [2]                     Client: abort [4]
s     |
u     |
m     |
e     |
  Yes |  Server: don't resume                   No problem
      |  Client: abort; server
      |    shouldn't have resumed

[1] Servers want to accept legacy clients. The draft[5] says that
resumptions SHOULD be rejected so that Triple-Handshake can't be done,
but we'll rather enforce that EMS was used when using tls-unique etc.

[2] The draft[5] says that even the initial handshake should be aborted
if the server doesn't support EMS, but we need to be able to talk to the
world.

[3] This is a very weird case where a client has regressed without
flushing the session cache. Hopefully we can be strict and reject these.

[4] This can happen when a server-farm shares a session cache but
frontends are not all updated at once. If Chrome is strict here then
hopefully we can prevent any servers from existing that will try to
resume an EMS session that they don't understand. OpenSSL appears to be
ok here: https://www.ietf.org/mail-archive/web/tls/current/msg16570.html

[5] https://tools.ietf.org/html/draft-ietf-tls-session-hash-05#section-5.2

BUG=492200

Change-Id: Ie1225a3960d49117b05eefa5a36263d8e556e467
Reviewed-on: https://boringssl-review.googlesource.com/4981
Reviewed-by: Adam Langley <agl@google.com>