HN Reader

> During the TLS handshake, the client tells the server which treeheads it has.

I don’t love the idea of giving every server I connect to via TLS the ability to fingerprint me by how recently (or not) I’ve fetched MTC treeheads. Even worse if this is in client hello, where anyone on the network path can view it either per connection or for my DoH requests to bootstrap encrypted client hello.

Next week at IETF 124, there's a Birds-of-a-Feather session that will kick off the standardization process here.

I think Merkle Tree Certificates a promising option. I'll be participating in the standardization efforts.

Chrome has signalled in multiple venues that they anticipate this to be their preferred (or only) option for post-quantum certificates, so it seems fairly likely we will deploy this in the coming years

I work for Let's Encrypt, but this is not an official statement or promise to implement anything yet. For that you can subscribe to our newsletter :)

There's no good reason to believe that quantum computers will break modern cryptography.

Shor's algorithm requires that a quantum Fourier transform is applied to the integer to be factored. The QFT essentially takes quantum data with a representation that mirrors ordinary binary, and maps it to a representation that encodes information in quantum phase (an angle).

The precision in phase needed to perform an accurate QFT scales EXPONENTIALLY with the number of qubits you're trying to transform. You manage to develop a quantum computer capable of factoring my keys? Fine, I'll add 11 bits to my key length, come back when you've developed a computer with 2000x the phase precision.

> During the TLS handshake, the client tells the server which treeheads it has.

If the first time the client doesn't know what root the server's certificate will chain to, therefore it doesn't tell the server what treeheads it has, and so the client gets a full certificate, and then the client caches this to remember for later connections, then... that could work, though it's a slight metadata leak.

Alternatively the client could send the treeheads for all the roots it trusts. That's going to bloat the ClientHello and... it's going to leak a bit of metadata unless if the client does anything other than claim to trust all roots blessed by the CA/Browser Forum, or the Chrome Root Program.

It worries me how we are increasingly making browser vendors a critical part of the TLS ecosystem - first with CRL bloom filters, now with signature Merkle trees. And they of course also manage the root stores.

Sure, it's nice and convenient if you're using an evergreen browser which is constantly getting updates from the mothership, but what is the rest supposed to do? How are we supposed to use this in Curl, or in whatever HTTP library your custom application code is using? How about email clients? Heck, is it even possible with embedded devices?

"The internet" is a hell of a lot bigger than "some website in Google Chrome", and we should be careful to not make all those other use cases impossible.

There's a section missing on the inclusion proof and what exactly the clients will be getting.

If I understand this correctly each CA publishes a signed list of landmarks at some cadence (weekly)

For the certs you get the landmark (a 256-bit hash) and the hashes along the merkle path to the leaf cert's hash. For a landmark that contains N certs, you need to include log2(N) * hash_len bytes and perform log2(N) hash computations.

For a MTC signature that uses a 256bit hash and N=1 million that's about 20*32=620bytes.

Is this the gist of it?

I'm really curious about the math behind deciding the optimal landmark size and publishing cadence

I think MTC is best described as a new signature algorithm for signing certificates where the value is a Merkle tree inclusion proof. This is quite clever. I like it.

> All the information a client needs to validate a Merkle Tree Certificate can be disseminated out-of-band.

The post didn't discuss it but naively this feels like it becomes a privacy issue?

I took some rough notes to whittle down the verbiage.

This proposal is to introduce PQ certificates in WebPKI such as for certificate authorities.

Problem is PQ signatures are large. If certificate chain is small that could be acceptable, but if the chain is large, then it can be expensive in terms of bandwidth and computation during TLS handshake. That is the exchange sends many certificates which embed a signature and a large (PQ) public key.

Merkle Tree Certificates ensures that an up to date client only needs 1 signature, 1 public key, 1 merkle tree witness.

Looking at an MTC generated certificate they've replaced the traditional signing algorithm and signature with a witness.

That means all a client needs is a signed merkle root which comes from an expanding Merkle Tree signed by the MTCA (Merkle Tree CA), which is delivered somehow out of band.

So basically TLS client receives certificate containing new signature algorithm which embeds a witness instead of a signature, a root (not sure if just a hash or a signed hash, I think the former). Client will get the signed roots out of band, which can be pre-verified, which means verifying the witness is simply doing a check on the witness.

Edit: My question: is this really a concern that needs to be addressed? PQ for TLS key exchange addresses a looming threat of HNDL (Harvest Now Decrypt Later). I don't see why we need to address making WebPKI use PQ signatures, at least for awhile now.

We could also just get rid of webPKI entirely?

But you still need a public key for TLS? Well, just put it in DNS!

And assuming your DNS responses are validated by DNSSEC, it would be even more secure too. You'd be closing a whole lot of attack vectors: from IP hijacks and server-side AitM to CA compromises. In fact, you would no longer need to use CA's in the first place. The chain of trust goes directly from your registrar to your webserver with no third party in between anymore. (And if your registrar or webserver is hacked, you'd have bigger problems...)

Quote:

  MTC also supports certificates that can be issued immediately and don’t require landmarks to be validated, but these are not as small. A server would provision both types of Merkle tree certificates, so that the common case is fast, and the exceptional case is slow, but at least it’ll work.

I am not so sure about the "exceptional" part

If the landmarks are generated not so often (say, once every couple of days), then the many clients will need to take the slow path

If the landmarks is generated quickly (once per hour ?), then the client will continuously download those landmarks

Here’s what I’m not following in general about the Post Quantum encryption studies.

Don’t we already just use the certificates to just negotiate the final encryption keys? Wouldn’t a quantum computer still crack the agreed upon keys without the exchange details?

Has the day finally arrived where "blockchain technology" is actually useful for something?

(I know its controversial what a blockchain even is, but this seems sufficiently close to how cryptocurrencies work to count)

Keeping internet locked, you mean?

Danke Merkle

Are we already talking about attackers having access to quantum computers?

I could see government agencies with a big budget having access to it, but I don't see those computers becoming mainstream

Although I could see China having access to it, which is problem.

share your design, sure, but there is no reason to suggest Q-day is imminent, the fear-mongering is utterly absurd.

Ah cloudflare. But who will protect us against cloudflare???

It's a privacy violating proxy after all.

Regardless of the strengths of this, I can't read this slop. A third of the way in, and:

> Instead of expecting the client to know the server's public key in advance, the server might just send its public key during the TLS handshake. But how does the client know that the public key actually belongs to the server? This is the job of a certificate.

Are you kidding me? You don't know your audience on an article at the nexus of certificate transparency and post-quantum cryptography well-enough to understand that this introduction to PKI isn't required?

Know your audience. Turning over your voice to an AI doesn't do that for you. It will waste everyone's time on thousands of words of vapid nonsense.