RE: [saag] fyi: tcpcrypt draft

[<[e-mail]>]

Hi Andrea,

> > tcpcrypt fundamentally does however have lower latency for connection
> > 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.

There's a problem here that needs attention.  As was pointed out in the tsvarea presentation (IIRC) of tcpcrypt, there is plenty of unpleasant deployment experience with at least middleboxes (e.g., firewalls) that discard TCP packets with unexpected header contents such as a new TCP option (or even attempted use of the ECN bits).  Sending the SYN with a new TCP option risks paying a long timeout with a site that doesn't support that new TCP option and has a middlebox that discards the SYN packet because it doesn't like the new option - that behavior will complicate incremental adoption.

What to do about this is a longer discussion, as some of the alternatives have downsides (e.g., starting both a tcpcyrpt and non-tcpcrypt TCP connections consumes an additional connection slot at the responder).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of David A. McGrew
> Sent: Monday, August 01, 2011 1:25 PM
> To: Andrea Bittau
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [saag] fyi: tcpcrypt draft
> 
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
>