On 07/30/2014 02:50 PM, David Mazieres wrote: > 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 see, thanks for the explanation. as MT says, in the legitimate use of
an RST bit (e.g. peer reboot), there will be no tcpinc framing at all.
>> 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.
"impervious to middleboxes" is different from your previous definition
of "will not be munged by middleboxes". Some misbehaving middleboxes
might munge arbitrary headers and will run afoul here.
If we protect these fields, that means that the recipient will do
something different if they do not validate. what do you think they
should do? ignore the bad packet? abort the flow? something else?
> I think RST and category 2 should be compatible with standard AEAD.
RST from the peer when it is not rebooting will be within the standard
AEAD. RST from the peer after a reboot won't be in AEAD at all.
Anything that fiddles with the protected TCP headers in an AEAD
construction will make whatever payload the packet has unreadable,
because the AEAD will return an error instead of decrypting.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
