Subject: [tcpinc] Proposal to support both uses cases

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 25 Oct 2015 12:11:45 +0100

Hi all,

writing as an individual contributor not as chair.

I’ve been think about these two use cases we’ve been taking about and though why don’t we support the two uses with the two different approaches. The two uses are:

1) The application is not tcpinc-aware and we want to provide opportunistic encryption.

2) The application implements TLS (1.3) and is tcpinc-aware and wants to use tcpinc/tcp-eno to negotiate TLS support with the other end.

Now want we can do is to use tcpcrypt as the encryption solution within tcpinc but also provide an interface where the application can say that it implements TLS and signal this in the tcp handshake to the other end.

This leads to the following three cases:

1) None of the ends have indicated that they implement TLS, therefore tcpcrypt is used. I guess in this case it doesn’t matter if we use tcpcryt or TLS on the wire. Might even be an advantage if it does not look like something know. And tcpcrypt is nicely integrated with tcp and might therefore be easier or at least more straight forward to also implement in there kernel.

Btw. as a side note: in this case both ends are not tcpinc-aware, this might not mean that they do not implement TLS and negotiate it. Probably we should detect this case to not double-encrypt.

2) One end implements TLS and tcpinc signals this support but the other does not. Thus in this case we still would have to use tcpycryt, while a TLS-only solution would in this case allow the app to use TLS. Thus here is a difference. But as tcpinc is anyway rather a transition technology, that might be an real issue.

3) And, of course, if both ends implement TLS and indicate this, the TLS implementation of the application is used and we simply have a nice way to negotiate TLS support in the tcp handshake. Even though that’s not spelled out in our charter, I think that's a nice use case for tcp-eno and we should support this case in any case.

Just my 2c. Let me know if that makes any sense to you!

Mirja

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Oct 2015 10:15:28 -0700

> 2) The application implements TLS (1.3) and is tcpinc-aware and wants to use tcpinc/tcp-eno to negotiate TLS support with the other end.

This appears to presume that tcp-eno is used only to negotiate tcptls.

Given tcp-eno cannot be used for TCP-AO, what's the point of having a
protocol to negotiate only one of three security mechanisms?

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 29 Oct 2015 13:53:46 -0700

> protocol to negotiate only one of three security mechanisms?

What are the three?  I think Mirja's proposal is that TCP-ENO could
negotiate between tcpcrypt and user-level TLS.  So that's two out of the
two protocols under current consideration.

AO is an authentication option rather than an encryption spec.
AO-encrypt in ENC-BTNS mode probably doesn't meet the security
requirements of ENO (the 16-byte ECDH limit could be problematic at a
time when even 32-byte curves are starting to be deprecated, at least
for top secret data).

That said, if you actually wanted AO-encrypt to work work with ENO, we
could make it happen.  That would require changes to your draft, of
course.  Specifically, you'd want to embed the ECDH nonces in a
variable-length ENO option rather than an AO option, and start using AO
only after the initial handshake.  You'd also have to up the key size,
probably to 32 bytes.  Personally, I would not at all mind seeing such a
protocol specified.  However, I got into trouble earlier for even
mentioning consuming so much SYN option space, so the initiative on this
would have to come from you.  If you need small, specific changes to
ENO, though, we'd be glad to try to accommodate you.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Oct 2015 15:42:40 -0700

On 10/29/2015 1:53 PM, David Mazieres wrote:
> negotiate between tcpcrypt and user-level TLS.  

It didn't appear that way from the post; it said to use tcpcrypt
opporunistically and use ENO only to negotiate the parameters for TLS (I
had thought that referred to Eric's TCP-TLS.

> could make it happen.

That could never protect the SYN itself, which is something TCP-AO-ENC
was intended to do. The AO variants protect the TCP header, which TCPINC
decided not to do. That's still (IMO) going to be important.

I.e., I see ENO as severely limited in this regard, and that needs to be
noted in the ENO doc.

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 29 Oct 2015 17:18:19 -0700

> I.e., I see ENO as severely limited in this regard, and that needs to be

I think you are conflating several issues here.  The working group
decided TCPINC will not protect the headers.  I wasn't necessarily in
favor of that decision, but I don't see any point in relitigating it,
either.  That means the working group will produce a TCPINC protocol
that does not protect TCP headers.  Fine.

However, the fact that TCPINC does not protect headers does not mean
that TCP-ENO cannot be used to negotiate protocols other than TCPINC
that do protect the header.  Indeed, one of the motivations for TCP-ENO
was that we felt the working group was letting the perfect become the
enemy of the good, and we wanted to be able to do something good without
closing the door to negotiating something better later on.

If it turns out that, independent of TCPINC, the TLS working group has
some use for TCP-ENO, then great.  Similarly, it would be nice if
AO-encrypt's ENC-BTNS mode could benefit from TCP-ENO.  I'm a bit
confused as to why you are talking about protecting the SYN header, when
your draft-touch-tcp-ao-encrypt-04 says:

        Initial SYN and SYN-ACK. The initial SYN (SYN and not ACK) and
        SYN-ACK segments are not encrypted or authenticated. Instead,
        their HMAC field contains the Diffie-Hellman nonce in network-
        standard byte order.

Correct me if I'm wrong, but I believe ENC-BTNS is the only mode that
could benefit from negotiation, since ENC-AUTH mode is configured out of
band.  So ENC-BTNS would seem a fine fit for TCP-ENO if you were willing
to modify your draft.  On the other hand, given that you already
officially own option 29, maybe you have no use for a protocol that is
illegally squatting on option 69.  (You've made your opinion on
squatting quite clear, no need to repeat it.)  But if you wanted to be
able to negotiate AO-encrypt alongside tcpcrypt and TLS, there's no
reason you couldn't participate in ENO.

David

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Oct 2015 10:56:51 -0700

On 10/29/2015 5:18 PM, David Mazieres wrote:
> that do protect the header.

TCP-ENO can't protect the SYN headers except if there are already
protections in place (ala TCP-AO). If that's the case, you don't need
TCP-ENO.

> Indeed, one of the motivations for TCP-ENO

That's fine, I'm just noting that TCP-ENO isn't really an option for
negotiating TCP security because TCP security includes TCP-AO. That
needs to be made clear.

> AO-encrypt's ENC-BTNS mode could benefit from TCP-ENO. 

Yes, that's the only possible use of TCP-ENO, and I would like to
explore that.

...
> band.

Correct - that was what I was raising (I wasn't focused on the ENC-BTNS
mode, but probably should be).

> So ENC-BTNS would seem a fine fit for TCP-ENO if you were willing
> squatting quite clear, no need to repeat it.) 

Let's suggest this for us both:

	- I update ENC-BTNS to use TCP-ENO
	
	- you update TCP-ENO to use RFC 6994 ;-)
	(at least until it becomes a standard)

> But if you wanted to be
> reason you couldn't participate in ENO

I can only negotiate AO-ENC-BTNS, as you note, but that's fine with me.
we'd have to figure out the issue of lengths, but I do already have a
draft in TCPM proposing a way to extend the SYN option space (we're
testing it now).

Joe

---

From: David Mazieres <[email-masked]>
Date: Fri, 30 Oct 2015 11:40:47 -0700

> protections in place (ala TCP-AO). If that's the case, you don't need

We should really subdivide this point to consider different levels of
protection.  Certainly TCP-ENO does not rule out retroactively
authenticating SYN segments.  Indeed, it even requires that encryption
specs at least authenticate the negotiation transcript.

However, the high-level model of TCP-ENO is to enable
application-specific authentication on top of generic transport-level
encryption.  So first you set up a connection, then you make some
cryptographically verifiable assertions about who is at each endpoint of
the connection.  If your goal is to protect against things like SYN-BOMB
attacks, ENO is never going to supplant AO.  But AO certainly could be
part of an ENO encryption spec that protects against things like
off-path RST injection or desynchronization.

> 	- I update ENC-BTNS to use TCP-ENO

Of course I'd be delighted to see this, particularly if there's any
chance of tcpm-tcp-syn-ext-opt or something similar becoming reality in
the near future.

> 	(at least until it becomes a standard)

Well, this is a working group decision now that the ENO draft has been
adopted.  Personally, I'd maybe prefer to see IANA's option assignment
lag behind reality rather than vice versa, but if a majority of the
working group feels the other way, I'd be happy to put in the work to
revise the draft.

Note that in ENO's case, the biggest casualty of RFC 6994 would be
layering ENC-BTNS on top of ENO, at least until tcpm-tcp-syn-ext-opt.
Having thought about this a bit, I think you can barely do it now and if
you consume two more bytes for an ExID it just won't work.  That said,
you may have a different approach, or tcpm-tcp-syn-ext-opt may be closer
than I had expected, in which case it would be great to have an
encryption spec ready to take advantage of large SYN options.  At that
point, it's also worth thinking more about how TFO fits into the
picture.

David

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Oct 2015 11:58:56 -0700

On 10/30/2015 11:40 AM, David Mazieres wrote:
> authenticating SYN segments.  

If you've acted on it there seems very little point in doing that. At
best, you're authenticating whether to continue the connection, but SYN
protection per se is gone.

> encryption.

(realizing this is a side issue) then it ought to be called APP-ENO.

> So first you set up a connection, then you make some

Agreed.

> layering ENC-BTNS on top of ENO, at least until tcpm-tcp-syn-ext-opt.

The only issue I see is whether to repurpose the ENO option on
subsequent segments for ENC-BTNS or to use the AO variant. If we didn't
reuse ENO, we'd have to decide whether to put the AO option in the SYN -
I don't know if it's reasonable to start using a new option after the
TWHS. I'll think further on that.

> point, it's also worth thinking more about how TFO fits into the

I wish that TFO would allow AO-style session keys of the new connection
using the TCP connection identifiers. E.g., TFO could avoid the need to
rekey new connections in that case.

Lots of stuff to consider...

Joe