Dear all, I've looked at draft-bittau-tcp-crypt, and I'm not sure I understand some parts. There are several possible ways to encode P-256 public keys in SEC1: it's not clear which have to be supported, and if we decide to include any new curves, something extra may need to be said. The key size for RSA is underspecified: the paper uses 2048 bytes, but the draft doesn't mention it.
The citation for PRF based MACs doesn't work in the case of Poly1305-AES-128 xored AES-128, as Poly1305 isn't a PRF. I'm sure the necessary result is true enough, but I'd have to do some work to show it. The DTLS and TLS proposals look very similar: why is one better than the other? There is no word on what features have to be supported, or guidance on what the kernel vs. the underlying application will do. The TCP-AO variant as it currently stands uses a 16 byte DH exchange. That's going to be very weak, even with elliptic curves. 32 bytes minimum works. SEC1 is not a network byte order encoding, it's a fixed length with a prefix. There is a lot missing from the draft: cipher choices, how negotiation works. If I had to implement one of these in the kernel, it would be the bittau draft. It's much simpler then alternatives, has running code, and comes with measurements of deployment effects. It explains how application layer can use the TCP connection for authentication and encryption by checking socket options. Sincerely, Watson Ladd _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
