On Fri, Aug 1, 2014 at 2:25 PM, Nico Williams <[email protected]> wrote:
> On Fri, Aug 1, 2014 at 4:14 PM, Eric Rescorla <[email protected]> wrote: > > On Fri, Aug 1, 2014 at 2:11 PM, Nico Williams <[email protected]> > wrote: > >> +1. Above all: integrity protection for the entire pair of data octet > >> streams. > >> > >> Required as an option, if not alway: confidentiality protection > >> (encryption). > >> > >> Obviously required: protection for any TCP options where not > >> protecting them implies failure to protect the data streams. > > > > Can you elaborate here? > > No, it's a corollary to the "integrity protection for the entire pair > of data octet streams". I could have left it out as implied. I could > go look at all the TCP options and make a list of which might need > protection and which might not, but that should be unnecessary at this > point: we're stating high-level requirements. > > >> Highly desirable: integrity protection for close/ EOF / RST. > > > > For reasons that people have already gone onto on the list, > > I think this minimally needs to be optional. > > Perhaps so. If middleboxes make that too hard then yes, it should be > optional, and probably default to off. (Though middlebox presence > could be detected by exchanging hashes of the SYN handshake, no?) > The issue isn't middleboxes; it's that if you require integrity protection for RSTs, then there's no way for a box that reboots to send you an RST. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
