On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > > > This last bit stops this, yes. I would prefer the spec say this very > > explicitly, as right now it doesn't and all I see is a line saying: > > "If any of these checks fail, the server MUST NOT respond with the > > extension and must discard all the remaining first flight data (thus > > falling back to 1-RTT)." > > Well, this is a general requirement any time the record MAC is bad: > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 > "If the decryption fails, a fatal “bad_record_mac” alert MUST be generated." > > > The current text doesn't explicitly say how to handle 0-RTT data that it > > thinks it should be able to decrypt but can't. After rereading things a bit > > I think you're correct in that the correct course of action the spec > > currently expects is to abort, however implementers frequently err on the > > side of working partially vs not at all when given any wiggle room. A clear > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this and > > avoid any other possible misunderstanding. Either do or do not; no try. > > > > If you have suggested text, I'd be happy to see a PR.
Except that when server is doing 1RTT fallback and skipping 0-RTT data, then records that get deprotect failure (is that the proper term?) are ignored instead of generating bad_record_mac like "normal" deprotect failure would. Then there's also the case where server is skipping 0-RTT data for retry (there one can recognize end of data from content-type 23 changing back to 22). Then one has to ensure that configuration_id's are never reused: If client and server disagree about server-valid configuration, the result can easily be hard failure (instead of fallback). One server-side trick to ensure non-reuse would be to hash the server certificate and the configuration messages (with configuration_id being zeroes of approriate length) using e.g. SHA-256 and then use the resulting hash as configuration_id. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
