On Mon, Dec 12, 2016 at 5:32 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > 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. > Right now, I believe it's legal for a client to send ClientHello, early data, and end_of_early_data alert without reading any messages from the server. This change would require a client to wait for the ServerHello before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
