On 13 December 2016 at 12:09, Eric Rescorla <e...@rtfm.com> wrote: > David Benjamin pointed out to me that end_of_early_data is the only place > where we transition keys on an alert and this would be cleaner if it was a > handshake message. This PR does that. It's encrypted under the same > keys, so this is largely an aesthetic issue, but I think a good one.
The major change in this PR isn't that obvious. And that is this: if the server has accepted early data, an EndOfEarlyData message will be sent to indicate [a] key change. This makes the end of early data signal conditional: a client that learns that its 0-RTT data has been rejected MUST NOT send the EndOfEarlyData message. The reason for this is that the EndOfEarlyData is a handshake message and therefore part of the handshake transcript. Presumably it appears after Finished (I'm going to send a PR that expands the ellipsis in the draft at least once, so that people can see the full canonical order). FWIW, I think that this is the right change, but some implementations will need to change in some non-obvious ways. I'm not aware of anyone who is rejecting 0-RTT and then decrypting the data so they can avoid a bunch of failed decryptions, but that approach won't work any more. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
