Re: [TLS] Merkle Tree Certificates

[David Benjamin <[e-mail]>]

Thanks for such detailed feedback! Responses inline.

On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara <[e-mail]>
wrote:

> Some quick comments / ideas:
>
> - I think it would be easier for subscribers to get inclusion proofs
>   from transparency service than certificate authority.
>
>   This is because issuance is heavily asynchronous, whereas most
>   servers assume ACME is essentially synchronous.
>
>   If certificates are canonicalized (this is mostly matter of ensuring
>   the names are always sorted), this could be endpoint to download known
>   inclusion proofs by certificate hash.
>
>   Or maybe even have both, and subscribers can use whichever is more
>   convinient.
>

We’re currently envisioning that the transparency services will potentially
vary by RP. They’re effectively the RP’s CT policy. The different TSs all
see the same trees, just later than the CA. It seems simpler then to get it
from the CA, which will be the least behind. This also means RPs can adjust
TS preferences without impacting subscribers or CAs at all. The equivalent
of a CT log migration and distrust is much less invasive.

Also, subscribers already talk to CAs via, e.g., ACME, so it seemed natural
to rely on that existing relationship. Especially as subscribers will need
a fallback credential from a CA anyway.

I suppose there’s no reason why the subscriber couldn’t fetch from the TS.
Though I’m not seeing how it would be more convenient. Could you elaborate?


> - I don't think there are any sane uses for >64kB claims, so the
>   claim_info length could be shortened to 16 bits.
>

Works for me. https://github.com/davidben/merkle-tree-certs/pull/29


>   I don't see rule for how claims are sorted within each type,
>   only how different types are sorted.
>
> - If each claim was in its own Claim, then one could maybe even
>   shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and
>   dns/dns_wildcard.
>
>   This could also simplify sorting: Sort by type, lexicographic
>   sort by claim contents.
>

Thanks! Yeah, the actual Claim bits were just a naive transcription of
X.509 SANs for now without much thought. I filed
https://github.com/davidben/merkle-tree-certs/issues/31 to track those.


> - I don't think anybody is going to use signatures with >64kB keys,
>   so subject_info length could be shortened to 16 bits.
>

Added to https://github.com/davidben/merkle-tree-certs/pull/29


> - What does it mean that in this document the hash is always SHA-256?
>

Just that the hash function used in building the trees, etc. is SHA-256.
(It’s the only ProofType we’ve defined. One could define others, but I
don’t particularly care to.)


> - Apparently issuer id is limited to 32 octets. This could be noted in
>   the definition.
>

Also added to https://github.com/davidben/merkle-tree-certs/pull/29


> - I think it would be easier if lifetime was expressed in batch
>   durations. Then one would not need window size, and especially not
>   handle lifetime / batch_duration not being an integer!
>

I think we’d still need to be able measure it in both units, but maybe I’m
missing something?

We need something in units of batch duration (currently window size) to
size the signed windows, etc.

But the RP can’t just use the window in lieu of expiry, because it can’t
simply assume all batches are valid, because the RP may be unable to fetch
new windows for a long period of time, such that the old (or all!) batches
have fallen off.

We could do that calculation in batch durations, but then we need to
measure the current time in batch numbers, which seemed unintuitive to me.
And then once that was in seconds, it didn’t seem that aligning it on batch
duration did much.


> - The root hash being dependent on issuer and batch number iff there
>   are multiple assertions looks very odd.
>
>   Empty assertion list might be special. But this also happens for
>   one assertion.
>

Thanks! That’s indeed inconsistent, we’ll fix it.
https://github.com/davidben/merkle-tree-certs/issues/32


> - I think LabeledWindow should add 64 spaces in front, so it
>   reuses the TLS 1.3 signature format.
>
>   This reduces risks of cross-protocol attack if the key gets
>   reused anyway (despite there being MUST NOT requirement).
>

Filed https://github.com/davidben/merkle-tree-certs/issues/30. I’m slightly
torn on this. The part of me that doesn’t trust people to keep keys
separate wants to do it. But the part of me that’s sick of chasing this
down in every new protocol would rather we just stop pretending using the
same key for multiple things is remotely sensible. :-)


> - Is there reason for type of trust_anchor_data to vary by proof_type?
>   Why not always have MerkleTreeTrustAnchor there?
>

The thinking was to be extensible for other proof types that may not have
the (issuer, number) structure. E.g. perhaps a fast-issuance model that’s
more analogous to X.509 with CT, if we get a meaningful enough improvement?

This isn’t strictly necessary. We could simply lift ProofType into
CertificateType and use the existing extension point. That would be simpler
in a lot of ways. But we thought this idea was interesting and wanted to
explore it.

Specifically, the subscriber doesn’t actually need to know anything about
the Proof contents. It only needs to know the Assertion (which identity am
I using?), and how to match TrustAnchors against the ClientHello or
CertificateRequest (which opaque proof will make the peer believe my
assertion?). This means, by making the right things opaque and with the
right deployment model, we could introduce new proof types without having
to update subscribers! There are far more subscribers than CAs, so this
could be attractive for agility.

Whether this idea will stick, I’m not sure. (I wasn't kidding about this
being truly a draft-00. :-) ) We could decide this property isn’t that
useful, or perhaps we can’t come up with an opaque TrustAnchor comparison
model that is flexible enough. I think that’ll depend a lot on how the
negotiation story shakes out, and that’s next in our queue to refine.
(We’ve got some ideas we want to write up here.)


> - And proof_data length field should probably be 16 bits. I don't think
>   proof_data will ever exceed 8kB.
>

8KiB might be tight for some signature-based ProofTypes if we reuse the
same structure (see above), but hopefully 64KiB is plenty?

I've put that in https://github.com/davidben/merkle-tree-certs/pull/29 too.


> - For type-independent expiry info to be helpful, this must be somehow
>   plumbed to the TLS server.
>

Yup! That is in the next batch of ideas we want to write up. :-)


> - Even if ACME itself allows for long processing delays, many (most?)
>   ACME clients do not.
>
> - Multiple orders from single newOrder or multiple certificates in
>   single order sounds like it would break assumption made in ACME
>   rather badly, and thus recipe for trouble.
>

This is a new format and all, and we already have to update things for PQ
once, so we’re assuming we can require one update to ACME clients to
implement whatever extension we define. (Existing ACME clients will just
continue to request X.509 certificates from their existing endpoints.)

Of course, to get to that one update, any such extension will definitely
need to slot in nicely with ACME’s existing model. We’re aiming to write
something up as an initial proposal, but I'm not an ACME expert, so this is
especially a place where feedback is welcome! I'm sure it will take
multiple iterations before we get it right. :-)


> - Isn't cert_type deprecated?
>

Is it? We weren’t planning on using it anyway (server_certificate_type is
just better), but I didn't find the document that deprecated it.


> - "We may need to define a third one.", you men fourth one?
>

Ah yeah, typo. Thanks! Fixed that in
https://github.com/davidben/merkle-tree-certs/pull/29


> - I think the uniform certificate format is already a requirement in
>   TLS 1.3. And OpenPGP format is banned in TLS 1.3 anyway. So parsing
>   to extension blocks without knowing certificate type is no problem.
>

Ah, that makes using CertificateEntry extensions more attractive, though
the processing order is a bit messy. I wasn’t able to find the requirement
you mention though. Do you have a pointer?

David