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?) _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
