Re: [quicwg/base-drafts] Add Advice and Rules for CONN_CLOSE in Initial and Handshake (#1786)

[Mike Bishop <[e-mail]>]

This is tricky, not just because you don't want an attacker to be able to inject the CC, but because all the mitigations themselves have ugly implications.

"Drop it" is a difficult directive -- if you mean drop the packet, what about other frames that you might have processed before encountering the CC frame?  Surely we're not adding a requirement that we be able to back out all interpreted frames if we encounter a frame that we don't like.

On the other hand, if you *don't* do that, then you're in an inconsistent state -- some of the frames that you've just consumed might have been attacker-generated and you've accepted them into the connection state.  Likewise if you only mean dropping the frame and continuing to process the rest of the packet.  That would argue for blowing up the connection as compromised anyway, which is exactly what would happen if you accepted the CONNECTION_CLOSE as valid.

Perhaps the most robust would be to require a first scan of any packet received at a lower encryption level than the highest ever seen (and always, for Initials) and reject the packet without processing any frames if illegal frame types are found.  (This is actually a compelling argument for making complex variable-length frames have an explicit length field, so they're easy to skip in this pass.)

Unless we do that, I'm inclined to think you don't fully trust a CONNECTION_CLOSE in Initial packets (perhaps not ever, or perhaps only after a short timeout to see if other Initials arrive), and you always trust and process a CONNECTION_CLOSE or APPLICATION_CLOSE from any other encryption level if you can validate the packet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1786#issuecomment-424837812