Hello Tcpcrypt authors,
I have skimmed the internet draft and the USENIX Security paper on
tcpcrypt, and while it is interesting and thought-provoking work, I
have a hard time understanding what the goals of the I-D are relative
to the TCP standard. The draft says "Standards Track"; would
Experimental be more appropriate? It mentions the following objectives:
"Tcpcrypt maintains the confidentiality of data transmitted in TCP
segments against a passive eavesdropper. It can be used to protect
already established TCP connections against denial-of-service attacks
involving injection of forged RST segments or desynchronizing of
sequence numbers." Yes, but TLS and IPsec perform the former
function, and IPsec and TCP-AO perform the latter. In addition,
running TCP over DTLS would also accomplishes the latter function;
this practice is done in some (so-called) SSLVPNs.
"Finally, applications that perform authentication can obtain end-to-
end confidentiality and integrity guarantees by tying authentication
to tcpcrypt Session ID values." This seems like a potentially useful
feature, though it seems similar to channel binding (RFCs 5056 and
5929).
"Tcpcrypt is designed to require relatively low overhead, particularly
at servers, so as to be useful even in the case of servers accepting
many TCP connections per second." The idea of batching signatures
seems like a useful contribution that could be put to good use by
servers that are under heavy loads. But why not implement this idea
in a way that could be used by multiple applications and protocols?
It should not be hard to define a format for digital signatures that
carries a few extra hash values, and allows a verifying party to check
the signature on the message that they care about, while ignoring the
rest. The idea of reversing the client/server association between RSA
encryption/decryption is a pragmatic way to help out servers, though
it is tied to a specific algorithm (the results would be quite
different for ECDH or ECDSA, say). Both of those performance
optimizations are definitely interesting, but I don't understand why
the best way utilize those ideas would be through a new cryptographic
protocol within the TCP layer.
I also have some comments on some other points. The USENIX Security
paper mentions the goal of ubiquitous encryption (though the draft
does not). Requiring changes to the TCP stack would hinder deployment
and work against the goal of ubiquity.
The draft describes the RSA public keys as "ephemeral", and the
companion paper says that the protocol achieves forward secrecy.
However, if it was really the case that a new RSA keypair was
generated for each exchange, then the performance would be
significantly worse than what is shown in the paper, because the cost
of that operation is significantly higher than that of RSA
decryption. I think the claims and/or guidance to implementers needs
to be clarified.
The Security Considerations section looks like boilerplate, while it
seems that there is a lot to be discussed, such as the security
properties of Session IDs.
Is it possible to relate the protocol to a previously analyzed
protocol? It is similar to ISO/IEC 11770-3, in that it relies on
public key encryption of nonces, without signatures. Perhaps there is
some analysis of that protocol, or of a protocol with cryptosuite
negotiation, that could be leveraged. The companion paper does have a
brief analysis of the security of the protocol, but it would be good
if it were possible to benefit from detailed analyses of all aspects
of protocol security. (I do realize that the analysis is made easier
by the relative simplicity of the protocol; that's a good thing.)
The security analysis defines the parameter "k ~ 256 is the minimum of
the min-entropy of a public key". Surely that doesn't match the 2048-
bit RSA examples in the paper?
As a side note, I am surprised to see a proposal to add so much
cryptographic functionality into the TCP standard, considering that
not many years have passed since the transport area declined to add
(much simpler) key transport functionality into TCP in support of TCP-
AO. Perhaps "Experimental" was intended, or perhaps I have missed or
misunderstood some aspect of this work.
regards,
David
On May 8, 2011, at 9:31 AM, Sean Turner wrote:
The authors of the following draft have asked that I forward this to
saag for comment:
https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/
They also noted that there's a Usenix Security paper and video:
http://tcpcrypt.org/docs.php
Please direct discussion to [email protected].
Cheers,
spt
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
