Subject: Re: [saag] fyi: tcpcrypt draft

From: "David A. McGrew" <[email-masked]>
Date: Mon, 1 Aug 2011 10:25:14 -0700

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-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Andrea Bittau <[email-masked]>
Date: Mon, 1 Aug 2011 12:14:07 -0700

On Mon, Aug 01, 2011 at 10:25:14AM -0700, David A. McGrew wrote:
> 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.

We have been considering this option throughout the work (and will still
do) but:

* No TCP header protection.  TCP-AO, which you suggest, does not
  interoperate with NATs.  We want something that works "out of the
  box".

* We can't leverage the 3-way handshake if operating at the application
  layer.  With tcpcrypt, we can do all session key negotiation in a
  4-way handshake (just one extra leg), or 3 if session caching.  Saving
  RTTs seems like a good thing.

>From a clean-slate perspective, it seems that integrating this into TCP
has all the advantages we're looking for.  Doing minimal work at TCP
(like a signle "do you crypto?" option) and doing the rest at an
application layer seems to come at a compromise (e.g., the drawbacks
listed above).

>From an implementation perspective, I agree that the least changes to
TCP are probably the best option.  tcpcrypt, at least for us, seems to
have a good balance between clean-slate and (relatively) few changes to
TCP, hence why we're pushing for it, as is.  If there were
non-implementation arguments as to app vs. transport layer we'd love to
hear those.

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Aug 2011 13:19:42 -0700

On 8/1/2011 10:25 AM, David A. McGrew wrote:
...
>> suggests that MACing TCP headers is important so crypto protocols should
> 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.

TCP-AO could easily support a mode where the TCP body was encrypted, 
e.g., where the encryption algorithm were defined to use the connection 
context (TCP header, IP pseudoheader) as context.

I had been planning on working that into the experimental TCP-AO NAT 
doc, since it could be as useful as the NAT variant.

That won't help initialize the keys, as would be needed before the SYN 
arrives for TCP-AO. That sort of in-band keying was excluded from TCP-AO 
to keep the SYN header size down.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Aug 2011 17:50:25 -0700

On 8/1/2011 5:37 PM, David A. McGrew wrote:
>
> On Aug 1, 2011, at 1:19 PM, Joe Touch wrote:
>
>>
>>
>> e.g., where the encryption algorithm were defined to use the
>> connection context (TCP header, IP pseudoheader) as context.
>
> It occurs to me that one of the downsides of having authentication via
> TCP-AO and encryption via TCPcrypt would be that authenticated
> encryption (AEAD) could not be used.

You would not want to cross the streams and use both options AFAICT.

>> arrives for TCP-AO. That sort of in-band keying was excluded from
>> TCP-AO to keep the SYN header size down.
>>
> Can TCP-AO possibly be used in a situation where the key is established
> after the initial message exchange, but there is no key available to
> both endpoints in the first exchange?

No; the assumption in TCP-AO is that a key exists during the initial 
exchange and AO is required. Keys can be changed later.

It would be trivial to set this up as a null key to start with if your 
goal is as you describe, though.

 > If so, is there a strong security
> requirement that militates against doing that?

Generally yes; it prevents AO from protecting you from SYN attacks.

You'd also need to change AO so that (depending on a flag set at both 
endpoints) you change the key after the SYN or not (e.g., increment the 
keyID or somesuch).

> It would be undesirable
> to have an endpoint set up a session (without authentication) then
> immediately have to tear it down (because when authentication was turned
> on, it became apparent that an active attacker had created or modified
> the messages). But perhaps if the "damage" is well contained and quickly
> discovered, it would be OK?

I don't know if this would be considered OK. I'd say it'd be easier to 
separate it into two steps, as hinted above:

1) an updated AO spec that allows a flag (on a master key, e.g.)
	that requires the keyID to be incremented after the SYN
	and that the first key can be null optionally

2) allow null keys (to enable the first part)

Null keys would expose the endpoint during the period they're used, on 
ports they're used. If the period were small (the SYN), then you could 
limit the damage AFAICT, but I'm not sure whether this would be 
considered sufficient or useful.

Joe

---

From: "David A. McGrew" <[email-masked]>
Date: Mon, 1 Aug 2011 17:37:42 -0700

> That won't help initialize the keys, as would be needed before the  
> SYN arrives for TCP-AO. That sort of in-band keying was excluded  
> from TCP-AO to keep the SYN header size down.
>

Can TCP-AO possibly be used in a situation where the key is  
established after the initial message exchange, but there is no key  
available to both endpoints in the first exchange?   If so, is there a  
strong security requirement that militates against doing that?   It  
would be undesirable to have an endpoint set up a session (without  
authentication) then immediately have to tear it down (because when  
authentication was turned on, it became apparent that an active  
attacker had created or modified the messages).   But perhaps if the  
"damage" is well contained and quickly discovered, it would be OK?

David

---

From: <[email-masked]>
Date: Tue, 2 Aug 2011 01:25:27 -0400

Hi Andrea,

> > tcpcrypt fundamentally does however have lower latency for connection
> > establishment compared to TLS due to fewer RTTs needed in negotiating a

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. McGrew
> Sent: Monday, August 01, 2011 1:25 PM
> To: Andrea Bittau
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [saag] fyi: tcpcrypt draft
> 
> Hi Andrea,
> 
> thanks for the detail.
>

---

From: "SCHARF, Michael" <[email-masked]>
Date: Tue, 2 Aug 2011 17:40:18 +0200

> From a clean-slate perspective, it seems that integrating 
> this into TCP has all the advantages we're looking for.  
> Doing minimal work at TCP (like a signle "do you crypto?" 
> option) and doing the rest at an application layer seems to 
> come at a compromise (e.g., the drawbacks listed above).
> 
> From an implementation perspective, I agree that the least 
> changes to TCP are probably the best option.  tcpcrypt, at 
> least for us, seems to have a good balance between 
> clean-slate and (relatively) few changes to TCP, hence why 
> we're pushing for it, as is.  If there were 
> non-implementation arguments as to app vs. transport layer 
> we'd love to hear those.

For whatever it is worth, the question of TCP extension vs. shim layer
seems to be somehow related to some discussions in the MPTCP WG last
year. In a different context, an expired ID
(http://tools.ietf.org/html/draft-scharf-mptcp-mctcp-01) discusses some
pros and cons of transport layer vs. shim layer+discovery by SYN
options. Not all of them are about implementation, and IMHO both
alternatives have disadvantages. Section 5.4 of RFC 6182 also includes
some thoughts.

Michael

---

From: Andrea Bittau <[email-masked]>
Date: Tue, 2 Aug 2011 14:17:54 -0700

> 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 t…

Yes, that's the crux of the argument - will a new TCP option cause
packets to be dropped?  In fact, that's the only compelling argument for
why an application layer approach might be better than a TCP one, though
we still think the arguments for TCP outweigh those for the application
layer.

We're working on measuring (the best we can) how much middleboxes drop
packets with unknown options to see whether it's a show stopper.
Hopefully the common case will be that middleboxes strip options rather
than dropping packets.  In fact, if you have pointers to case studies on
middlebox behavior we'd love to have those.

As you say the solution is not straightforward.  For example, a very
conservative approach could be to disable tcpcrypt if the sender is
unable to connect using tcpcrypt to (say) three sites.  That way the
penatly of sending a vanilla TCP syn and a tcpcrypt SYN to "path probe"
is paid only three times.  tcpcrypt can be turned back on when the
sender's IP changes.  This may work out pretty well if our test results
show that middleboxes are most often found closer to the client-side
(e.g., NATs) rather than the server side.

My understanding of most of ECN's problems is that the bits were
previosuly reserved and then overloaded.  TCP options (in principle) are
a by-the-spec way of extending TCP, so hopefully we'll suffer less
problems compared to ECN.

---

From: Andrea Bittau <[email-masked]>
Date: Tue, 2 Aug 2011 14:31:01 -0700

> alternatives have disadvantages. Section 5.4 of RFC 6182 also includes

Mark Handley is in fact one of the authors of tcpcrypt and RFC 6182 so
we're working closely with him to figure out what the implications of
TCP options are in practice.  Section 5.4 of RFC 6182 concludes that TCP
options are the right way to go and hopefully that applies to tcpcrypt
too (we're working on it with Mark).  All tcpcrypt authors agree that
TCP is the right place for encryption from a design perspective, though
the one practical downside are middleboxes.  We're hoping we can
"handle" most cases by downgrading to TCP by checking if the options
make it through on the SYN / SYN-ACK.  A pretty bad case is when the SYN
is dropped.

For us to better present an argument (or perhaps even change our
design!) we're trying to figure out what the arguments are for an
application layer approach as opposed to a transport one.
Implementation has already come up.  From a design perspective however,
apart from middleboxes (or even more specifically, SYNs getting dropped)
we'd be glad to hear more opinions on why the application layer might be
more attractive.

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 3 Aug 2011 14:44:50 +0300

Hi,

Michio Honda has recently performed experiments on exactly these issues of extending TCP; the results are reported in an IMC paper to be published later this year that Michio and us have co-authored.

I can send the paper to interested people (please email me directly) but can't send it on this list because it is still not in its final form.

The paper probes 150 access networks (including home, hotspots, 3g providers, cable, etc) to check and see if new  TCP options get through, and whether middleboxes resegment the TCP stream. 
There are many other tests there, but those are not necesarily relevant to tcpcrypt. The paper does not probe the server end of things where firewalls, load balancers and the like can cause further  grief.

The new options get through on SYNs on 86% - 96% of the paths we probed. The percentage depends on the TCP port (only 86% allow new options on HTTP traffic, 94% on HTTPS traffic, and 96% for a new, unknown port).
SYNs with new options were never dropped; in the remaining 4%-14% of the cases the new options were simply removed.

As for middleboxes that resegment the bytestream: this behaviour did appear in the tests, but it was correlated with the removal of new options on SYNs. Basically, middleboxes that resegment tend to terminate the connection and open a new one to the destination, acting like a full proxy.

We've analyzed all experimental data and its implications for about mptcp and tcpcrypt: the result is that these two protocols seem safe to deploy today in the access networks we've probed. 

Cheers,
Costin