libp2p TLS 1.3 Handshake

[marten-seemann]

In the last couple of weeks I spent a lot of time designing a TLS 1.3 based handshake for libp2p. This document has come a long way, and I managed to remove a lot of the complexity, while at the same time preserving the future extensibility which I originally built into this version of the protocol.

This is a proposal how we can run the libp2p handshake using TLS 1.3 in the future. Since we're currently only using secio in production, we are completely free to design things the way we want, without having to worry about backwards compatibility. That means that now is the right time to criticize every single aspect of this protocol.

I already implemented a proof of concept in libp2p/go-libp2p-tls#20, feel free to play around with that code as well.

[anacrolix]

Could you include why we want TLS 1.3-like handshakes? Is it because of 0-RTT, or just keeping up with the times?

[magik6k]

Do we do this only because Go doesn't support some protocols in it's TLS implementation?

[marten-seemann]

That's one reason, the other is #111.

[marten-seemann]

@anacrolix it’s in the design considerations. TLS 1.3 just takes a single round trip, older versions take two. And there’s little reason to roll out a new Handshake protocol on top of an old TLS version anyway.

[Kubuxu]

Q: Which public key is signed?
Q: I feel like it should somehow be bound to TLS session we are establishing. Otherwise, this proof could be "stolen" and reused by someone else.

[marten-seemann]

It's the public key used to generate the certificate. I'll update the PR to clarify that.
Why do you want to bind it to the session that we're establishing? What we're doing here is basically creating a certificate chain, with the host key at the root. Just that we're not using x509 certificates, due to the limitations described earlier.

[yusefnapora]

I initially thought that the publicKey field of SignedKey was referring to the host key. I think it's this sentence which is a bit ambiguous:

The peer signs its public key using the its host key.

Since you were just talking about the public key for the peer ID in the prior paragraph, I assumed that's what "public key" referred to here.

It's clearer down below, where it says "The publicKey field of SignedKey contains the public key of the endpoint", although it wouldn't hurt to spell out that the endpoint key is the one used to generate the certificate.

Since it is the endpoint key being signed, if you wanted to have the proof be bound to the session as @Kubuxu suggests, you could just generate a new key and self-signed certificate for each session. Is that correct @marten-seemann?

[Kubuxu]

I'm still not clear about which keys, public keys and certificates are being sent over and in which fields.

I don't see cleanly that the chain confirming ownership of key used in TLS handshake is bound to a PeerID.
I have few ideas regarding possible attacks, and possible reuse in case TLS key is leaked but first I need to understand this part fully.

[Kubuxu]

I'm reading it again so bear with me.

[marten-seemann]

Sorry for the confusion here. You sign the public key that was used to generate the certificate with your host private key.

The reason is that the key used to generate the certificate is used by TLS during the handshake to sign the CertificateVerify message. By signing the public key of the certificate we get a chain of verified signatures.

Using the host's public key would be a bad idea. An attacker could just copy the contents of the libp2p Public Key Extension and use that to impersonate this peer. We really need an operation that proves that the peer actually meant to use the key used by TLS.

[tomaka]

Most importantly, it would make us vulnerable to downgrade attacks.

[tomaka]

What about the protocol string in multistream-select? That's a version negotiation mechanism.

[Stebalien]

Yes but we may want to speak TLS before multistream. That is, we should allow peers to advertise /ip4/.../tcp/443/tls/ipfs/Qm... directly. This should help disguise IPFS traffic.

[marten-seemann]

That works for TCP, but not for QUIC. In QUIC, the first packet sent by the client already contains the ClientHello.

[tomaka]

That seems redundant with #100

[Kubuxu]

So my main issue is this sentence, I don't understand the difference between public key and host key.

[burdges]

As Noise is more flexible than TLS 1.3, we might support specific Noise handshakes for specific nodes roles, but TLS 1.3 supports cipher suite agility and conceivably helps obfuscate traffic, but only if integrated with the web-like transports.

As a naive first approximation, we might consider (a) replacing secio with Noise in a way exploits Noise's flexibility, (b) integrate TLS 1.3 with the web-like transports in a way that really permits blending in with web traffic, and (c) correctly permit both Noise and TLS 1.3 to manage authentication using key provided by the application. In fact, there is an enormous nasty can of worms involved in doing traffic obfuscation like I suggest in doing (b), for which the Tor project recruits an army of young, idealistic, and talented developers to write pluggable transports, and for which U.S. State Dept pays them like $2 M per year. We should not compete with them here, so maybe the correct solution for obfuscation is actually TLS 1.3 or Noise running over Tor pluggable transports.

We're left with TLS 1.3 being the only secure protocol with cipher suite agility, and Noise providing more handshake flexibility. Increasingly, we view cipher suite agility as harmful, based in part on how hard doing it correctly proved for TLS, so modern protocols should dump cipher suite agility and simply version instead. IPFS appears rather committed to cipher suite agility though.

[raulk]

Looks like a good start! Thanks, @marten-seemann.

1. I'd suggest adding a formal definition of the different keys and how they relate to each other.

2. To my understanding, the peer generates an ephemeral per-session key, and produces a self-signed certificate without using the host key. This certificate then embeds (via certificate extensions) the host's permanent identity public key, and a signature of that public key with its pairing private key.

   Unless I'm mistaken, isn't this scheme subject to man-in-the-middle attacks, where one could replace the outer certificate by extracting the inner host key and injecting it into a new certificate produced with a key they control? I'm sure I'm missing something. It seems there is no cryptographic crosslink between the host key and the ephemeral session key.

P.S.: as per one of my comments, I think using ephemeral session keys oughts to be a MUST requirement, as otherwise we would not guarantee Perfect Forward Secrecy.

[raulk]

IMO another reason for not using the host key directly is to achieve Perfect Forward Secrecy.

[marten-seemann]

TLS 1.3 uses ephemeral Diffie-Hellman for the key exchange mechanism, so it's always PFS, no matter what kind of certificate you use.

[raulk]

I think generating a new key per session should be a MUST, otherwise Perfect Forward Secrecy might be compromised.

[marten-seemann]

Let me expand on my earlier comment. In TLS 1.3, the client send a key_share extension in the ClientHello. This key share is the client's ephemeral DH key (i.e. it is a fresh value for every connection). The server sends its part of the ephemeral DH key share in the key_share extension in the ServerHello.
Since TLS 1.3 decouples key exchange mechanism from the signature algorithms, TLS 1.3 handshakes are always forward secure, no matter what kind of certificate you use.

By the way, you might have heard of eTLS 1.3. It's supposed to be used by businesses who want middleboxes to be able to decode their traffic (and who don't care about their customer's privacy). It removes PFS from the protocol by having the server send a static key share in the ServerHello. The sad thing is, there's no immediate way to detect a server that's misbehaving in that way, other than running heuristics over multiple connections.

[marten-seemann]

@burdges

As Noise is more flexible than TLS 1.3, we might support specific Noise handshakes for specific nodes roles, but TLS 1.3 supports cipher suite agility and conceivably helps obfuscate traffic, but only if integrated with the web-like transports.

I'm a bit skeptical about obfuscation. As you note, obfuscation done right is really hard, and we even fail at the most basic aspects. The first one is that you'd have to run your node on port 443, a request to a non-standard HTTPS port will immediately stick out. Second, there's the ALPN extension which is sent unencrypted in the ClientHello, and I'd like to avoid putting a fake value into that field. And then there are hard parts like traffic patterns, which are very characteristic for HTTPS traffic, which will probably be impossible to replicate in libp2p.

As a naive first approximation, we might consider (a) replacing secio with Noise in a way exploits Noise's flexibility, (b) integrate TLS 1.3 with the web-like transports in a way that really permits blending in with web traffic, and (c) correctly permit both Noise and TLS 1.3 to manage authentication using key provided by the application.

The advantage of TLS 1.3 at this point is that we can use the same handshake logic on TCP and on QUIC. Noise looks really interesting and we might be able to use it on top of TCP, but it's not obvious how to integrate it into the QUIC handshake.

[marten-seemann]

@Kubuxu I just pushed an update that (hopefully) makes it clear which key I'm referring to. Can you please have another look?

[Kubuxu]

It is much clearer now.

One issue I see (and it is a small issue that depends on our threat model) is if ever the private key for the outside certificate was leaked, it gives the attacker an ability to impersonate owner of the host key forever.

What do you think about this?

[Kubuxu]

I've created this diagram to make it easier to understand:

Source

@startuml
top to bottom direction
object "Cert Key" as certKey


package "x509 Certificate" {
object "Certificate" as cert {
  libp2p Public Key Extensions
}
certKey -[#blue]-> cert : signs

object "libp2p Public Key Extension" as pke {
    hostPubKey : PublicKey
    signature
}

object signature
}

cert --* pke
pke --* signature

object PeerID {
  hostKey
}
PeerID -[#blue]> signature : signs
pke .> PeerID : hostKey proves 
signature .> certKey :  prooves
certKey -[hidden]-> signature
certKey -[hidden]-> pke
certKey -[hidden]-> cert


@enduml

[marten-seemann]

@Kubuxu: Thanks for the diagram!

One issue I see (and it is a small issue that depends on our threat model) is if ever the private key for the outside certificate was leaked, it gives the attacker an ability to impersonate owner of the host key forever.

That's true, but I'm wondering if this is a realistic threat. After all, losing your host key would also allow an attacker to impersonate you forever (obviously). If at all, the host key will be more vulnerable to be compromised, since it's typically written to disk (at least for IPFS) and loaded into memory, where as the key for the outer certificate only needs to exist in memory.
That being said, an easy mitigation for this would be to attach an expiration date to the signature, so an attacker could only impersonate the host until that signature expires. Not sure if the additional complexity is justified. What do you think?

[Stebalien]

The key used to generate and sign this certificate SHOULD NOT be related to the host's key.

This precludes the optimization we talked about where a peer MAY derive the certificate key from the host key and the verifier MAY skip verifying the signature in the extension if the key matches the certificate key.

I guess SHOULD allows implementations to do what they want, but we may want to say that implementations MUST NOT reject certificates that use the host key.

[marten-seemann]

Yes, SHOULD means that you're not supposed to do it, unless you think you have good reasons for it. I've described some measurements I did in the Design Considerations, section Why we're not using the host key for the certificate, which led me to conclude that this optimization is not worth it. Do you agree?

[Stebalien]

It probably isn't but there's no reason to preclude it. Basically, I just don't want some over-zealous dev to reject these keys.

[marten-seemann]

Sure, that's why it's a SHOULD. SHOULD implies that you can't rely on the peer following the recommendation, so I don't think any additional text is needed.

[Stebalien]

Some discussion here: https://github.com/libp2p/specs/pull/100/files.

[marten-seemann]

We have a bunch of specs that only live in PRs now, but don't seem to be blocked by anything major. We should get them merged some time, so we can properly refer to them.

[Stebalien]

Mostly blocked on reviews, IIRC. But yeah, we should just get MVPs merged and mark them as drafts.

[vyzo]

that's a bit of a hole here, let's at least make it compatible with negotiation in the future.

[Stebalien]

Ideally, that's what (2) below provides. We can use the SNI field as it's sent in the first packet.

[Stebalien]

(LGTM)

[Stebalien]

Ideally, that's what (2) below provides. We can use the SNI field as it's sent in the first packet.

[jacobheun]

Added some minor copy corrections. Overall I think this looks good to mark as Draft and merge.

[tomaka]

For what it's worth, the rustls library (Rust-TLS), which is used by quinn, the only viable QUIC implementation in Rust at the moment, seems to always reject self-signed certificates on purpose (rustls/rustls#143).

If I were to implement this on a short time frame, I'd generate a CA certificate, embed it in the source code as a trusted source, and sign the ephemeral certificates from this CA. But that means we wouldn't be compatible.

[tomaka]

What's the exact string name of the extension to use when generating the certificate?

[marten-seemann]

I'm not sure I understand the question. You can find the OID further down in the document.

[marten-seemann]

For what it's worth, the rustls library (Rust-TLS), which is used by quinn, the only viable QUIC implementation in Rust at the moment, seems to always reject self-signed certificates on purpose (rustls/rustls#143).

This sounds like something that should be fixed in rustls. Accepting self-signed certificate should be a basic feature of any TLS library. I really don't want to increase the length of the certificate chain to work around that shortcoming (thereby increasing the number of signature verifications to be performed during each handshake as well as significantly increase the number of bytes transmitted). Any estimate how long would it take to get this fixed in rustls?

[tomaka]

Accepting self-signed certificate should be a basic feature of any TLS library.

That's debatable. I'm pretty sure the authors of rustls would disagree.

[Stebalien]

They probably don't want to blindly trust self-signed certificates but I doubt they'd object to a custom certificate validator if cleanly implemented.

[marten-seemann]

@tomaka I'd like to merge this PR very soon. What do you think is the best way forward here?

[burdges]

You should fork the required library and use Ed25519 using agl's libraries.

ECDSA kinda works but.. secp256k1 should be avoided anyways, due to side channel concerns. RSA should not even be considered for any current use cases, although supporting it for whatever strange future scenarios sounds harmless..

[Stebalien]

Really, we might wan to rephrase this in terms of ecosystem support. That is, TLS is a rather complicated protocol and we don't want to force libp2p implementations to add support for new key types.

[marten-seemann]

You should fork the required library and use Ed25519 using agl's libraries.

I considered that, but concluded that's it's not a good solution. It would mean pulling in a forked x509 package, and in order to use that one, we'd also have to fork tls just to change the import path.

[tomaka]

As a general remark, in my opinion whether or not a library exists in the ecosystem should only be a very minor consideration when writing specs. You want your specs to do the right thing, not the thing that can be implemented the most easily.

[tomaka]

Which is why I didn't answer your question "Any estimate how long would it take to get this fixed in rustls?" (#151 (comment))
To me how long something takes to implement is not relevant when discussing specs.

[burdges]

Filo has a branch at golang/go#25355 I'm surprised this takes google so long given agl's role in Ed25519 being accepted by standards bodies.

[marten-seemann]

@tomaka: Is there any way to define a custom certificate verifier in rustls. Or if that’s not possible, could you temporarily add the certificate to the root CAs until it is verified?
Would using a different TLS library be an option? I saw that there are multiple TLS 1.3 implementations in Rust.

[tomaka]

Is there any way to define a custom certificate verifier in rustls. Or if that’s not possible, could you temporarily add the certificate to the root CAs until it is verified?

It is possible to have a custom verifier, but once a connection is established it is not possible to know which certificate it corresponded to (cc libp2p/rust-libp2p#211 (comment)).
However that can probably be fixed by tweaking rustls.

Again, the specs shouldn't be based on whether they are easy to implement.

[marten-seemann]

@tomaka Are you ok with merging the specs as they are now, or do you think we need to change anything?

[tomaka]

I'm fine with merging that!

My "regret" is that the libp2p handshake will still be distinguishable from an HTTP handshake, but there's no way to fix that as far as I know.

[Kubuxu]

@tomaka I'm not sure if it will be distinguishable, TLS1.3 establishes encrypted (not authenticated) channel after ClientHello and ServerHello. Certificate, CertificateRequest are sent in a separate message: EncryptedExtensions.

I think this should make libp2p handshake and https handshake roughly the same.

[marten-seemann]

@tomaka: The cleartext messages of the handshake will be identical to an HTTP handshake if we use the same ALPN (the spec doesn't say anything about which ALPN to use, so we're free to specify that later). However, as long as people don't run their nodes on port 443, and connect from random port numbers, libp2p traffic can be easily distinguished from genuine HTTP traffic just by looking at the IP header.