On Sunday, December 27, 2015 11:55:16 pm Christian Huitema wrote: > On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote: > > 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 > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftlswg.gith > > ub.io%2ftls13- > > spec%2f%23rfc.section.5.2.2&data=01%7c01%7chuitema%40microsoft.com%7 > > c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4 > > 7%7c1&sdata=nTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d > > > "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. > > Isn't that a part where TLS and DTLS will differ a lot? > > For DTLS, we have to consider the packet injection threat. It is fairly easy > to send some random bytes with a fake source to a UDP destination. Such > attacks should not cause the DTLS association to fail! The normal behavior > ought to be to just ignore UDP packets that fail to decrypt. This would cause > 0-RTT rejects to just result in dropped packets. Can we ensure that the > handshake protocol is robust against that?
One idea might be to include a hash of all early data records' ciphertext in the "early_data" extension. This lets them stay out of the handshake hash yet still have their hash be covered by it. So long as servers verify all successfully decrypted early data records against this hash before processing them further, and abort if something is missing, then this could be done safely. More complex, though. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
