Daniel Kahn Gillmor <[email protected]> writes: > I like this analysis. Is there any reason we can't apply it to the > items in category 2 as well as RST?
The reason it applies to RST only and not other data is that any authenticated packet containing the RST should have the RST bit authenticated. The complication with RST is not that we want to tolerate middleboxes flipping the RST bit, but rather that RST packets are the only packets an endhost might legitimately send after forgetting the session key. So the question an endhost must answer upon receiving an unauthenticated RST is, "Do I believe that the other endpoint has forgotten the session key?" This is quite separate from any middlebox issues. > I note that we won't be able to fold these headers into a standard AEAD > construction with this approach, since stuffing RST and category 2 > headers into the AD spot will mean that any munging of the protected > header info would cause the payload to fail to decrypt, which removes > the ability of the receiver to decide whether it cares about these > protections. (This is an argument against Martin Thomson's TLS-based > proposal, as i understand it) Not sure I understand this. Category 2 values are the ones that are impervious to middleboxes. Category 3 values are the ones that could get changed by middleboxes and cause decryption failure. I think RST and category 2 should be compatible with standard AEAD. But tcpcrypt uses ASM mode for more pragmatic reasons, because we want it to be very efficient to compute or update the ACK number when the rest of the packet is not in the CPU cache. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
