Hi Andrea,
thanks for the detail.
On Jul 29, 2011, at 6:45 PM, Andrea Bittau wrote:
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).
Yes, valid points. It would be good to add this motivating text to
the draft.
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?
Got it. I would state it this way: while TLS can be used to protect
any TCP application in principle, in practice it is not always
available, and introducing it into an application protocol requires a
mechanism for advertising and selecting to use TLS where it is
available, and falling back on unprotected communications where it is
not available.
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.
Agreed; but note that this is a far different statement than "36 x
better performance", which if I recall right was stated in the
presentation at IETF81. It is important to provide a detailed
comparison, especially to the non-crypto audience who might miss the
full implications.
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 will be especially interesting is to see how the reversal of RSA
private/public key operations compares to ECC as a function of
security level.
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.
This sounds like an option worth pursuing, no pun intended. You make
good points about why TCP is a good place to do the capability
discovery and fallback for crypto. Why not define a TCP option that
can enable devices to discover TLS or tcpcrypt or other higher-layer
crypto protocols? That option would be much easier to implement and
standardize, and it could tie into a full tcpcrypt protocol that
resides in a shim above the TCP layer. The separation will create
useful implementation alternatives, and will isolate the TCP state
machine from changes.
For concreteness, I'm thinking of a TCP option that looks like this:
+---------+---------+-------------------+
| Kind |Length=2 | SECCAP |
+---------+---------+-------------------+
The Security Capabilities (SECCAP) field contains an unsigned integer
that indicates
the cryptographic security protocol, if any, the endpoint can use to
protect subsequent
communications.
SECCAP Value Meaning
0 Reserved for future use
1 No security protocol is available
2 TCPcrypt
3 TLS
... ...
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).
True, but why not design tcpcrypt so that it make use of TCP-AO?
That seems like an approach that would work with the separation
outlined above.
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.
Unfortunately that is not always a safe assumption. There are
standards for RSA key generation (see for instance NIST SP 800 56-B
Section 6.3.1) in which n bits of random data are used to seed a
pseudorandom process that selects the primes used as the private key;
for 1024-bit RSA, n will be about 80.
I am confident that tcpcrypt can be made to work around this fact, but
it may be an important detail (in the security proof if not in
practice).
David
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
