Comment by jiveturkey | Hacker News Reader

Comment by jiveturkey | Hacker News Reader

> In particular, tcpcrypt does not protect against active network attackers unless applications authenticate the session ID. If it can be established that the session IDs computed at each end of the connection match, then tcpcrypt guarantees that no man-in-the-middle attacks occurred unless the attacker has broken the underlying cryptographic primitives, e.g., Elliptic Curve Diffie-Hellman (ECDH).

What am I missing here? An active attacker will just terminate the connection on both ends. There will be 2 authenticated session IDs at L3. At L7, how will an application authenticate the L3 ID in such a way as to discover a MITM? Even if it can, there needs to be a new ioctl (or similar) for the application to learn the L3 ID. That's rough for the large legacy of applications that might otherwise benefit from this.

I'm sure I'm missing it, since this has been 10 years in the making, authored by well known folks. The referenced USENIX paper discusses how both ends of the tcpcrypt connection can know there's no MITM. However, in the case of intercept, the other end of the connection is the MITM.

Because tcpcrypt uses ephemeral public keys, there's no L7 identity proof, such as is offered by TLS (as far as it can). This further permits MITM.

An active attacker can also just strip the TCP-ENO bits from the SYN. If [just] one side insists, the attacker can strip it just from the other side, for performance.

They introduce a new IOCTL which you can use to discover the session id and then authenticate it however you like.

In particular, it is possible to use a zero knowledge protocol where a MITM attacker cannot determine if authentication were actually used or not except via changes in user behavior if there are any. For protocols which have a mixture of authed and non-authed usage, this can create a significant risk of discovery for an active attacker.

In any case, authentication is inherently tied up with "identity" which is significant UI and application specific considerations which simply do not exist for ephemeral encryption. TCPcrypt achieves an appropriate layering which separates these concerns while killing content observation by passive attack and increasing the risk of detection otherwise.

Re: stripping, again-- how to handle the absence of encryption is also an application relevant decision. TCPcrypt provides sufficient tools for applications to set appropriate policies.

> They introduce a new IOCTL which you can use to discover the session id and then authenticate it however you like.

> In particular, it is possible to use a zero knowledge protocol where a MITM attacker cannot determine if authentication were actually used or not except via changes in user behavior if there are any.

I'd love for you to expand more on this. What I can't think of is a realistic scenario where it's possible to validate the session id in a secure way, but there is also some reason that we couldn't just use TLS with client certificates.

> I'd love for you to expand more on this. What I can't think of is a realistic scenario where it's possible to validate the session id in a secure way, but there is also some reason that we couldn't just use TLS with client certificates.

An example would be if you don't have a certificate. Maybe you just have a pre-shared secret or a kerberos ticket. Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session. Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle.

> An example would be if you don't have a certificate.

Given that letsencrypt exists, I don't see why you wouldn't have a cert.

> Maybe you just have a pre-shared secret or a kerberos ticket.

The pre-shared secret could be a cert which would work with TLS.

> Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session.

I can't think of a realistic example of such a protocol. What protocol uses PAKE, but doesn't support encryption, but will verify a session id? It seems like using TLS would be simpler.

> Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle.

Such a scenario still requires modifications to the NFS server and client software, which, if done, isn't clear why it would be better than just layering TLS onto the protocol.

> Given that letsencrypt exists, I don't see why you wouldn't have a cert.

That makes an enormous number of assumptions-- that you have a domain name, that you accept inbound connections, and that "gee some server connected to my name and got me once" is a remotely acceptable criteria for identity in your application.

> What I can't think of is a realistic scenario where it's possible to validate the session id in a secure way, but there is also some reason that we couldn't just use TLS with client certificates.

TLS with client certificates requires securely getting and certifying the certificates. Somehow. Yet many alternatives exist.

For some applications keys might exist in dns-- but in others no dnssec or names could be assumed.

For some applications the endpoints can be assumed to have a shared password, so some SPAKE can be used to authenticate.

For some applications an identity exists in some external consensus system that the other side can provide proof from, but which doesn't fit into the x509 model. (For example, if you wanted to use keys registered in namecoin to authenticate your identity).

For some applications you would like to use an anonymous group signature: "This user is on the authorized list, but beyond that, I don't want to know what user this is."

For some applications each party should be cryptographically unidentified, anonymous, and indistinguishable to from any other party unless both of their keys match, because otherwise you could track the parties around the internet from IP to IP. TLS/client cert lets you achieve this for one side-- you can decline to send the client cert if the server identity isn't to your liking, but you can track the server's identity around.

None of these examples fit nicely into the TLS/x509 model. All of them, including something functionally equivalent to TLS+x509clientcerts can be implemented on top of TCPcrypt.

Reply on news.ycombinator.com