Sorry for the late reply! Comments inline.
On Tue, May 10, 2011 at 04:03:58PM -0700, David McGrew wrote:
> 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:
We don't have a strong opinion about a standard's track vs.
experimental categorization, so experimental is fine. We'll be happy to
reevaluate in the future.
> "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.
Yes, tcpcrypt immediately offers confidentiality of data against a
passive eavesdropper, which is better than the status quo, but this is
not our ideal situation. Our ideal situation is to provide strong
secrecy and integrity protected by mutual authentication of the two
endpoints. The benefit of tcpcrypt is that it immediately provides this
protection against passive eavesdroppers, while also making it as easy
and efficient as possible to achieve the stronger security when
applications can make use of appropriate authentication credentials.
While IPSec is capable of providing opportunistic encryption, it does
not do so "immediately". In particular, plenty of machines run
operating systems that support IPSec, yet do not use IPSec for security.
Tcpcrypt, by contrast, is designed to be "on by default." It therefore
has to require less configuration and provide better interoperability
than IPSec with middleboxes such as NATs. IPSec, because it is at the
network layer, is also harder to integrate with application-level
notions of authentication, which are typically tied to a particular TCP
connection rather than a pair of machines. (E.g., it is reasonable to
run two different browsers on the same client, and use those two
browsers to log into the same web site with two different accounts.)
TLS is closer to tcpcrypt. It could also be used for opportunistic
encryption. However, compared to tcpcrypt, TLS still requires more
configuration, is not compatible with all TCP applications, and has a
heavier impact on server performance. All of these factors make it
harder to enable TLS by default. The combination of TLS and TCP-AO (the
latter requiring setting up a pre-shared key between endpoints) would be
harder still to make on by default. Finally, the fact that TLS does not
always provide forward secrecy is a disadvantage compared to tcpcrypt.
Being a single, integrated, zero-configuration (once kernels support it)
solution that can be incrementally deployed puts tcpcrypt at an
advantage compared to other solutions that need to be used in tandem for
more complete security, each coming with their own configuration
requirements.
> "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).
Yes it's the same concept and we implemented in tcpcrypt's core to allow
briding to app-level authentication. We also use the same mechanism to
name sessions for session caching.
> "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.
The optimization is independent of tcpcrypt. In fact, tcpcrypt's
standard doesn't mandate nor specify any authentication mechanisms -
it's left to the application. Batch signing is just an example of
how one might authentication tcpcrypt sessions. It can be done with
other protocols if they permit it.
Note that this optimization cannot be used in stock SSL because of SSL's
design. SSL requires the server to perform an (expensive) private key
operation per client because each client sends over a unique encrypted
pre-master secret which the server decrypts to prove its identity (i.e.,
that it knows the private key for the certificate it advertised to the
client). So to leverage batch signing we need to design protocols that
allow for it, hence why we created tcpcrypt clean-slate.
We do have a drop-in replacement for OpenSSL that attempts to use
tcpcrypt+batch signing if able otherwise reverting to SSL. This can be
used by many existing SSL applications without modifying them but just
replacing the system's SSL library.
> 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 protocol is designed with incremental deployment in mind which
hopefully will lead to ubiquitous encryption. Specifically:
* It tries tcpcrypt and falls back to TCP gracefully. The app doesn't
* have to know anything about tcpcrypt.
Sure, modifying the TCP stack hinders deployment. So would modifying
all applications (which is potentially even more difficult). We need to
modify something to get encryption, and for the reasons just mentioned
about incremental deployment we think TCP is the right place to do it.
> 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.
It's not perfect forward secrecy (i.e., one key per connection). More
like one key per 10 minute window or whatever the system is configured
to.
> 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.
Yes, we agree - this is just a first draft. Well work on improving
that. If this is taken on by the IETF, no doubt things we haven't
thought of will be pointed out.
> 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.)
We agree, and we'll work on this.
> 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?
The paper says: "where k ~ 256 is the minimum of the min-entropy of a
public key, or the length in bits of NS or NC."
NS and NC are random 256-bit values, so their min entropy is 256. The
public key is a product of two 1,024-bit primes, so its min entropy is
much higher than 256.
The min entropy is just the probability of running the key generation
function twice and getting the same public key out the second time.
This has nothing to do with the difficulty of breaking RSA (which for
2,048-bit keys would be sort of equivalent to a 112-bit symmetric key).
The difficulty of breaking RSA is irrelevant to our reduction. We are
saying that if you can break tcpcrypt, we can break the public key
algorithm or one of the other cryptographic functions in a "black box"
way, without regard to what the algorithms actually are.
> 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.
We think the perceived use case for TCP-AO was a replacement for TCP-MD5
in BGP sessions. Of course TCP-AO is broader than that, but the
perceived use case may have influenced the previous decision.
