Subject: Re: [saag] fyi: tcpcrypt draft

From: Andrea Bittau <[email-masked]>
Date: Wed, 27 Jul 2011 11:42:57 -0700

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.

---

From: Andrea Bittau <[email-masked]>
Date: Fri, 29 Jul 2011 18:45:44 -0700

On Thu, Jul 28, 2011 at 07:33:05AM -0700, David A. McGrew wrote:
> A lot of work has been done on using IPsec to solve these problems,
> and it is important to explain in detail how tcpcrypt improves on
> this work.  Besides the opportunistic encryption effort, there is
> BTNS (draft-ietf-btns-channel-binding-api-00 defines channel
> bindings for IPsec, for instance), RFC 3947 for running IPsec over
> NAT.  (Half joking: would the configuration of
> draft-ietf-ipsec-internet-key-00 with NAT-T solve all or most these
> problems?)

tcpcrypt makes incremental deployment easier because probing is built
into existing packets and fallback comes at no extrea cost.   When a SYN
packet is sent out and tcpcrypt is not supported at the other end, we
can fallback to regular tcpcrypt at no extra cost - just carry on with a
vanilla TCP handshake.  How would this work with BTNS or IPSec?  Do you
probe for IPSec (and then probe for NAT-T), wait for a timeout, and then
send a TCP SYN?  If so, it adds network overhead (extra packets) and
latency (probe timeout).

tcpcrypt also has less protocol (space) overhead.  NAT-T requires
encapsulating IP in UDP, and NAT seems like a common deployment
scenario.  It also requires opening more ports on a firewall and
configuring additional services (NAT-T).

> What TCP applications can't use TLS?   Do you mean that some apps
> don't use TLS in current implementations, or that there is some
> basic incompatibility?

There's a bootstrap problem.  If I have SMTP on TCP/25 I have to assume
it's clear-text (I can't send an SSL handshake packet).  Thankfully,
SMTP is an extensible protocol and I can send STARTTLS and then go on
with SSL.  If the protocol didn't permit any "options" / commands, I'd
be stuck to plain-text.  I'd have to allocate a new port.  That makes
incremental deployment harder - do I send two SYNs?

> What about running TCP on top of DTLS?   That would protect the TCP
> session, while keeping the crypto separate from the TCP stack.

Same answer as per BTNS and NAT-T - we can efficiently incrementally
deploy and have less protocol overhead.

> 1.  How easy to configure will tcpcrypt be once it supports mutual
> authentication, the enforcement of configurable security policies,
> and crypto algorithm agility (e.g. ECDH and ECDSA)?

Authentication is left to the application, so tcpcrypt will support
authentication only if the application supports it.  If the application
supports it, then a mechanism is already in place, e.g., htpasswd in
Apache for passwords.  So in the case of Apache, it'll include
tcpcrypt's session id when doing http digest authentication, for
example.

We're also working on an authentication library that attempts to
authenticate tcpcrypt using DNSSEC+DANE that can be used by all apps if
DANE is deployed.  The configuration will require storing a certificate
fingerprint in DNS.

We expect that most applications (e.g., the ones running clear-text                                          
today) won't care about the crypto algorithms used in tcpcrypt's
handshake.  So the security policy will be set system-wide (e.g., allow
only RSA, SHA1 or whatever).  For security concious applications it'll
be a setsockopt and presumably those applications already have a
configuration file for whatever the already use today for crypto.

> 2.  The comparison of tcpcrypt to TLS is only considering the RSA
> ciphersuites in the latter protocol.  The efficiency and security
> properties of other ciphersuites are quite different.

Yes, but we expect tcpcrypt to be no worse (or better) than TLS.
tcpcrypt fundamentally does however have lower latency for conncection
establishment compared to TLS due to fewer RTTs needed in negotiating a
key (we leverage the 3-way handshake and add only an extra leg),
especially when session caching.

> 3.  Reversing the client and server public/private key operations in
> tcpcrypt, which is used to make the protocol more scalable, is
> applicable only to the RSA algorithm.   In particular, the situation
> with elliptic curve cryptography is quite different.  This raises
> some questions: how does tcpcrypt with RSA compare to an ECDH/ECDSA
> TLS ciphersuite, say, at security levels of 128, 192, or 256 bits?
> How does tcpcrypt perform with other algorithms?   Given the
> interest in ECC as a future direction for cryptography, these
> questions deserve some thought.

Yes, we'll implement those but we do not expect tcpcrypt's performance
to be much different from a TLS implementation - we both do the same
thing (e.g., ECDH).

> What you are describing here is true for the RSA ciphersuites in
> SSL, but is not true for the Diffie-Hellman ciphersuites, or the
> ECDH ones (see Section 7.4.2 of RFC 5246 for instance).

tcpcrypyt's main goal is to be deployed ubiquitously.  Improved
performance in one case is only a bonus.  It has a bunch of other
advantages (single integrated mechanism, incrementally deployable) apart
from RSA performance.

> Why is graceful fallback easier at the TCP layer than at another
> layer?   And if there is some mechanism within TCP that facilitates
> fallback, would it be possible to use that mechanism in conjunction
> with a cryptographic protocol external to TCP?  That last option
> would minimize the impact to TCP implementations, meaning less new
> code inside kernels, and fewer states, and so on.

Gracefully, and efficient, I should add.  The problem is detecting
whether the other end supports crypto mechanism X.  At a below-transport
layer, we'd have to send our IP packet, wait for a timeout, and then
send a SYN.  At a transport layer we're sending out a SYN so we can
easily piggyback options (perfect!).  At an application layer what's the
first thing we send?  STARTTLS?  Does the application-layer protocol
allow such new commands or will it drop the command?

The minimum TCP mechanism needed for a graceful and efficient fallback
is a TCP option in the SYN.  So, tcpcrypt-lite would modify a kernel
with a setsockopt(CRYPTO_OPTION) to include the CRYPTO option in a SYN
and getsockopt(CRYPTO_OPTION) to see if the CRYPTO option was echoed in
the SYN-ACK.  At that point SSL_accept() can be called.  But we lose all
TCP header MACing - e.g., someone can RST our connection.  TCP AO
suggests that MACing TCP headers is important so crypto protocols should
do that (hence why we live in the transport layer).  Also, we can
leverage the existing 3-way handshake to get a head start on crypto
negotiations.  Sesison caching completes within the three way handshake.

> If the RSA keypair is generated using a pseudorandom process (and
> there are standards for doing that), the min entropy could be lower.
> 
> But if it is adequate to have the entropy show up in the nonces, the
> min-entropy of the key would be a moot point.

The pseudo-random generator has to have enough state to generate prime
numbers with min entropy 256.  Depending on the prime number generator,
this might, for instance, require something on the order of 256 + ceil
(log_2 (log_e (2 ^ 1024))) or 266 bits.  We assume most RSA
implementations would have more random state than that.