Re: [saag] fyi: tcpcrypt draft

[Andrea Bittau <[e-mail]>]

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.