On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote: > 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." > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > 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.
Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT records aren't allowed special treatment and errors on handling MUST NOT result in a 1-RTT fall back. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
