On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 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. > Thanks for pointing this out. I agree with this assessment. We could of course exclude it from the transcript but that seems silly. 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. > Actually you could, just discard EOED in that mode. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
