Subject: [perpass] tcpcrypt - worth another look?

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Sep 2013 10:12:51 +0100

Hi,

Jeff raised tcpcrypt [1] in his earlier email.

When this proposal came up a few IETFs ago, I was against
it on the basis that we already have IPsec and TLS so why
would we want yet another way to protect TCP sessions? Esp.
since it didn't seem to allow the flexibility of IPsec or
TLS in terms of key mgmt, nor have a DTLS variant etc etc.

Maybe I was wrong.

I'm not sure I was, but I do think its at least worth
looking at again.

I guess that tcpcrypt does do opportunistic encryption of
TCP sessions, which now seems more attractive. A bit more
heterogeneity in the infrastructure might also be useful
and maybe some of the MITM attacks on TLS that have been
done wouldn't be nearly as easy on this. (The ones where
a CA has been subverted.) And now that MPTCP is going to
attempt to be moved to the standards track, that will
need better security than the experimental MPTCP RFC has,
and this could do that.

On the negative side, I'm not sure if this is still a
live proposal, nor if it'd really get traction. I just
don't know if using the data portion of segments works
for key exchange. tcpcrypt doesn't currently seem to
support PFS if public keys are re-used either. I guess
there're also a bunch of other bits and pieces in there
that'd need work as well. This might also be over-the-top
for MPTCP's needs. And maybe we'd be better off putting
effort into opportunistic encryption at the IP layer and
in TLS.

I'd be interested in knowing what folks think about that.

Personally, I'm not sure, but if there were a groundswell
of support for progressing tcpcrypt then I at least would
be more interested than I was a year ago.

Thanks,
S.

[1] https://tools.ietf.org/html/draft-bittau-tcp-crypt

---

From: Mark Handley <[email-masked]>
Date: Tue, 17 Sep 2013 04:06:07 -0700

tcpcrypt has been mostly dormant for the last couple of years, as we
didn't really gain traction in the IETF last time round.  I (and I
believe my co-authors) still believe that tcpcrypt (or something
similar) is a key part of moving forward on improving general Internet
security, and especially on large-scale passive eavesdropping.  We're
happy and ready to put in energy if there's interest now.

The key reason for an approach at this layer in the stack is that it
gets you the most bang for the buck.  By leveraging the TCP handshake,
you can get sessions encypted very easily with minimal infrastructure
deployment, and only a single change to the stack.  It's much harder to
do that at the IP layer because there's no handshake, and it's hard to
roll out _everywhere_ above TCP (it shouldn't really be so hard, but all
the evidence of the last couple of decades is that it is).  

So our philosophy is:

 - Separate encryption from authentication.    

 - Encryption is easy, and application-independent.  Enable encryption
 by default, using ephemeral public keys for key exchange.

 - Authentication is hard and application-dependent (which also makes it
 dependent on the TCP port - different TCP ports need different
 authentication).  Provide the hooks in tcpcrypt to support a wide range
 of authentication in applications running over the top of tcpcrypt.

 - Provide a hook in tcpcrypt so each end knows if the other end's
 application is capable of negotiating the next layer.  

We also showed how to do key exchange fast in servers, so there should
be little cost of enabling it.

In the long run we'd hope all TCP sessions would be encrypted, but
wouldn't expect all to the authenticated.  An interesting benefit is you
cannot tell from eavesdropping whether or not an encrypted session will
also be authenticated.  This makes mounting a MITM attack risky if you
want to go unobserved.

As for PFS - tcpcrypt allows key resuse, but discourages doing too much
reuse.  It's up to the implementation how frequently to generate new key
pairs, but it would be easy to do this in the background when idle. 
Whether you get PFS or not depends on how often the keys are reused (you
can choose to never reuse, at some cost), but keys are never kept around
for long. There's certainly no CA to subvert as far as encryption is
concerned.

Cheers,
Mark

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
> 
> 
>

---

From: Mark Handley <[email-masked]>
Date: Tue, 17 Sep 2013 04:23:41 -0700

By the way, if you want an intro to tcpcrypt, it's probably best to
start with the Usenix Security paper:
http://tcpcrypt.org/tcpcrypt.pdf
It does a better job of explaining what we're trying to achieve than the
internet draft.

Or as a quick intro, the video of the Usenix Security session by Andrea
Bittau:
http://tcpcrypt.org/talk.php

Cheers,
Mark

---

From: Norbert Bollow <[email-masked]>
Date: Tue, 17 Sep 2013 16:13:31 +0200

Mark Handley <[email-masked]> wrote:

> deployment, and only a single change to the stack.

I've tried to find (in the draft or in the paper) information on the
server's entropy consumption, and the practical consequences.

Can entropy generation become performance-limiting on servers that
receive a lot of connection requests?

What kind of source of randomness did you use in the experiments?

Greetings,
Norbert

---

From: Mark Handley <[email-masked]>
Date: Tue, 17 Sep 2013 09:09:39 -0700

> What kind of source of randomness did you use in the experiments?

That is a good question.  I don't know what Andrea's implementation
currently does.

A few thoughts (but it would be better to ask one of the security people
on the draft rather than me):

A busy server will be handling a lot of packets per second, and the
precise arrival times (as measured by CPU cycle counter) of those
packets is not predictable, so the more traffic a server receives, the
more entropy it has from this source.  This helps less if you've got an
eavesdropper very close to the server, but precise arrival times will
still have some unobservable entropy.

We could require the client supplies another random (encrypted) nonce
right after the key exchange.  This would be sufficient to top up the
entropy pool in the presence of a passive eavesdropper, assuming entropy
generation is easier at the client.  An active attacker could try to
deplete this entropy source by making a lot of connections and sending
known values of this nonce, but they'd have to drown out all the
legitimate clients, which would be difficult on a busy server, and would
likely reveal the presence of the attack.  And they'd need to combine
this with eavesdropping very close to the server, or all they'd do is
add randomness to the pool from their packet arrival times.

Regards,
Mark

---

From: Watson Ladd <[email-masked]>
Date: Tue, 17 Sep 2013 09:23:07 -0700

> add randomness to the pool from their packet arrival times.

Exhibit A of why we need mathematicians on this list. The difference
between AES in counter mode and
actually random numbers is miniscule. Any server has enough entropy to
reseed say once a second, which will be fine for
less than 2^64 connections per second. Please, check what /dev/urandom
actually does, and what actual cryptographers say
about generating random numbers in practice.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Sep 2013 17:36:52 +0100

On 17 Sep 2013, at 17:23, Watson Ladd <[email-masked]> wrote:

> Exhibit A of why we need mathematicians on this list.

Not necessarily this list. Our job for now is to identify bits of work that'll help and people who are willing. Perfecting the details will be for elsewhere in most cases.

S

---

From: Mark Handley <[email-masked]>
Date: Tue, 17 Sep 2013 09:54:40 -0700

On Tue, Sep 17, 2013, at 09:23 AM, Watson Ladd wrote:
> On Tue, Sep 17, 2013 at 9:09 AM, Mark Handley <[email-masked]>

> Exhibit A of why we need mathematicians on this list. 

And precisely why tcpcrypt is the result of a collaboration with people
like Dan (who doesn't usually hang out on IETF mailing lists).

Norbert's original question was not a dumb question though, even if the
answer is there's nothing to be concerned about.

Mark

---

From: John-Mark Gurney <[email-masked]>
Date: Tue, 17 Sep 2013 09:38:10 -0700

> about generating random numbers in practice.

Also, the randomness is only needed when a new client connects or we
decide to rekey an existing host.  A single host can connect many
additional times w/o requiring additional entropy.

It does look like there cannot be a DoS attack against the entropy
pool as the sever doesn't need to generate N_S until the client has
responded to PKCONF and they must response w/ the proper ACKCOOKIE if
the server provided a SYNCOOKIE in the PKCONF packet.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Sep 2013 18:39:42 -0500

> Jeff raised tcpcrypt [1] in his earlier email.

I personally thought tcpcrypt was an awesome idea. It was, IIRC, "down talked" by some of the people who have been more instrumental in blocking other solid security suggestions, like zRTP. Possibly even for technical reasons, but that's a debate worth reliving.

Perhaps we could also consider a "policy" level of document, perhaps a BCP, that sets high goals for security and surveillance resistance in all new work.  A formal declaration that fundamental security IS a priority, that protocols lacking it "harm the Internet" just  as badly as those lacking congestion control.

--
Dean

---

From: Brian Trammell <[email-masked]>
Date: Wed, 18 Sep 2013 07:56:41 +0200

> I personally thought tcpcrypt was an awesome idea. It was, IIRC, "down talked" by some of the people who have been more instrumental in blocking other solid security suggestions, like zRTP. Possibl…

+1. In doing so, we should also make sure that either the mechanism is applicable to alternate transports under consideration for the HTTP/2 effort, or that those transports have equivalent mechanisms for opportunistic encryption.

> Perhaps we could also consider a "policy" level of document, perhaps a BCP, that sets high goals for security and surveillance resistance in all new work.  A formal declaration that fundamental sec…

+n.

IMO, this would be an update of RFC 2804, which would say in effect "remember when we said it's not okay for us to work on protocols that allow through their design the surveillance of targeted parties (point 4 of the wiretapping definition in section 3: "...when the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest")? it's also not okay in the case that everyone is a target."

(I was about to say we could just strike point 4 from the definition there, but in the interests of pedantry we should probably rework the definition, since one could say that points 1 and 2 don't hold in the case of pervasive passive surveillance, since post-Snowden/Poitras/Greenwald, everyone has a reasonable suspicion that everything which can be delivered to any third party by any means available.)

Cheers,

Brian