Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 10, 2023 at 05:09:10PM -0500, David Benjamin wrote:
>
> I've just uploaded a draft, below, describing several ideas we've
> been mulling over regarding certificates in TLS. This is a draft-00
> with a lot of moving parts, so think of it as the first pass at
> some of ideas that we think fit well together, rather than a
> concrete, fully-baked system.
>
> Thoughts? We're very eager to get feedback on this.

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.

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

  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.

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

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

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

- 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!

- 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.

- 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).

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

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

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

- 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.

- Isn't cert_type deprecated?

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

- 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.




> On Fri, Mar 10, 2023 at 4:38 PM <[e-mail]> wrote:
> 
> >
> > A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt
> > has been successfully submitted by David Benjamin and posted to the
> > IETF repository.
> >
> > Name:           draft-davidben-tls-merkle-tree-certs
> > Revision:       00
> > Title:          Merkle Tree Certificates for TLS
> > Document date:  2023-03-10
> > Group:          Individual Submission
> > Pages:          45




-Ilari