"Scharf, Michael (Michael)" <[email protected]> writes:
> Unless I miss something, the difference between tcpcrypt and a > solution running in the TCP payload (again, to me a TLV design does > not have to be TLS) is that the tcpcrypt code audit has to analyze the > complete TCP stack, whereas in case of a TLV protocol in the payload > the code review just comes down to reviewing a narrow-scoped > (kernel-internal or kernel-external) library handling the encryption > on top of the existing, security-hardened TCP byte stream transport. One nice thing about tcpcrypt's design is that it layers very nicely below TCP. So if you start from the premise that your TCP implementation is okay between two honest implementations, tcpcrypt can be implemented without touching existing TCP code. Indeed, the user-level implementation does not require any changes to kernel TCP stacks. It's basically just a 1:1 packet rewriter. (The only exception is a timer for lost INIT2 segments.) We plan to start work with Kestrel on a verified linux tcpcrypt implementation soon, and our hope is to do this without having to verify the whole TCP stack. We understand that header protection is no longer in the cards. Depending on the sentiment at the meeting next Thursday, we may therefore change tcpcrypt to a TLV protocol. There are certainly valid arguments for TLV, but I suspect it will add implementation complexity by increasing the cross-product of tcpcrypt and TCP states. For example, on the inbound path, you must now buffer both unverified segments and unconsumed but verified+decrypted data, where this new unconsumed data buffer increases code size and attack surface. The TLV question basically comes down to whether we want TCPINC to be layered underneath TCP (like tcpcrypt, mostly doing packet rewriting) or on top of it (like TLS-use-TCP, relying on TCP's reliable stream). As a programming abstraction, TLV will look a lot more like today's TLS than TCP. At a high level, maybe that's okay, since TLS already works over TCP and both provide a reliable bytestream abstraction. But there is more to TCP than just read and write. So that forces a whole bunch of subjective design decisions about how much of TCP's semantics we want TCPINC to preserve. E.g., what happens when the length of a TLV message exceeds the advertised window? Should there be any attempt to preserve a connection with a single corrupted packet? Should SO_LINGER wait for secure EOF acknowledgment? If we had a working TCP-use-TLS implementation to kick the tires on, we could get a better sense of how people like one particular set of answers to these questions. If they do, then just as TCP-use-TLS borrowed a lot of ideas from tcpcrypt, I'd feel more comfortable moving towards their semantics for a TLV version of tcpcrypt. But I see TCPINC's purpose as specifically catering to applications that, for one reason or another, have not yet adopted TLS; otherwise, today's TLS would be the solution. For that reason, in the absence of more data, my inclination is to favor traditional TCP semantics over TLS ones. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
