Subject: Re: [perpass] tcpcrypt - worth another look?

From: Mark Handley <[email-masked]>
Date: Tue, 17 Sep 2013 04:13:39 -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

> 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
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
> 
> 
> 
_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

-- 
Mark

---

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

Hi Mark,

> happy and ready to put in energy if there's interest now.

Great. So anyone else here think that's a good plan and
might get traction?

I'd also be keen to know if you've any thoughts on the mptcp
question - do you think tcpcrypt could be a real option for
mptcp security?

Cheers,
S.

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Sep 2013 07:40:02 -0400

With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly  so
interesting.

---

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

On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote:

  With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly
  so interesting.

QUIC is pretty interesting as a protocol and does a lot of things that
TCP should have evolved to do.  From a security point of view, if I
understand the design documents correctly, it's really a drop-in
replacement for TLS/TCP.  Thus it seems to suffer from the same issues
TLS does - not enabled sufficiently frequently (you can argue about
why, but we've been doing that for a very long time), and dependence on
the CA infrastructure.  Thus it seems likely to be mostly deployed in
places that already do TLS.

QUIC could, of course, take the same approach as tcpcrypt.  Do
encryption by default using ephemeral public keys, even with no
configuration, but provide the hooks to enable various forms of
authentication.  From what I've read, it doesn't seem to do that.
Please correct me if I misunderstood though.

Cheers,

Mark

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Sep 2013 06:43:28 -0600

> With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly

Is there an equivalent to tcpcrypt for UDP?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Sep 2013 15:48:59 +0300

> Is there an equivalent to tcpcrypt for UDP?

In some sense you could just use DTLS (for UDP) and TLS (for TCP) 
without server-side authentication and you are done with it.

The real challenge is to get the deployment out there.

Ciao
Hannes

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Sep 2013 10:04:51 -0400

Now that I'm out of bed and at a device with a real keyboard, I can
elaborate.

I hope Mark will forgive me, but I've envisioned the birth of tcpcrypt as
something like: Student: "Mark, you know that conversation we had two weeks
ago about research projects related to MPTCP?  I figured out how to do low
overhead encryption for TCP."  Mark: "That's great.  We can bundle it with
MPTCP and take it to the IETF. Maybe we can find a way to make it generally
useful."  :-)

There is a trend toward putting capabilities in what I'm going to call the
session layer (if you don't like that I'm glad to call it something else -
that's not the main point), of which QUIC is an example.  Partly this is
because the behavior of the transport layer isn't very consistent anymore.
 The great thing going on in HTTPbis, RTCWeb, etc. is they might get a good
level of behavioral consistency.  And if they do, they will attract even
more feature building.

This leads me to believe that that level/layer is a really good place to
put consistent security capabilities.

Scott

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Sep 2013 17:15:18 +0100

On 17 September 2013 13:17, Mark Handley <[email-masked]> wrote:
> QUIC is pretty interesting as a protocol and does a lot of things that TCP
> should have evolved to do.  From a security point of view, if I understand
> the design documents correctly, it's really a drop-in replacement for
> TLS/TCP.  Thus it seems to suffer from the same issues TLS does - not
> enabled sufficiently frequently (you can argue about why, but we've been
> doing that for a very long time), and dependence on the CA infrastructure.
> Thus it seems likely to be mostly deployed in places that already do TLS.
>
> QUIC could, of course, take the same approach as tcpcrypt.  Do encryption by
> default using ephemeral public keys, even with no configuration, but provide
> the hooks to enable various forms of authentication.  From what I've read,
> it doesn't seem to do that.  Please correct me if I misunderstood though.

You are right, but there's no reason not to extend QUIC to do
ephemeral encryption. That wasn't the use case we were thinking about
when we designed it.

Seems like a useful thing for the IETF to consider.

---

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

> Seems like a useful thing for the IETF to consider.

Agreed - seems like a very useful thing to work on, and would probably
help QUIC reach applications and scenarios it otherwise wouldn't be used
for.

I think that shouldn't stop us trying to fix TCP as well though - indeed
the QUIC design docs talk about retrofitting QUIC mechanisms to TCP in
the long run.  Not sure if that's still the intent.  But getting
deployment of ephemeral encryption in QUIC is certainly likely to be
faster :-)

- Mark

---

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

Hi Ben, Mark,

> Seems like a useful thing for the IETF to consider.

So does someone have some concrete next steps in this master
plan? (Which sounds interesting to me at least.)

Maybe make a proposal to the tcpm wg to adopt tcpcrypt,
examine tcpcrypt as an approach for mptcp and then start
on a QUIC-with-similar-crypto or something?

If its too early for that last step, is someone gonna
propose one or both of the others?

Or something else?

This being the IETF, someone needs to push it along or
nothing will happen.

Cheers,
S.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 24 Sep 2013 11:21:11 +0100

> propose one or both of the others?

We're certainly interested in bringing QUIC to the IETF. Extending it
for ephemeral sounds like a useful thing to me.