Opened 5 years ago

Closed 5 years ago

#162 closed defect (fixed)

Bound the set of artifacts a log is expected to produce

Reported by: rlb@… Owned by: eranm@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

This is far more work than is required for the protocol to function. In order
to provide relying parties with evidence that a certificate is included, it
should be sufficient for the log to maintain:

  • For each certificate, a single inclusion proof to an STH
  • Consistency proofs between any two STHs

Right now, a log is required to produce much more than this minimal set. For
example, the "get-sth-consistency" endpoint requires the log to either
dynamically compute an inclusion proof on demand, or compute fresh inclusion
proofs for every certificate every time a new STH is issued.
This has several unfortunate results:

  • The contents of a log are effectively un-cacheable because (a) they are so numerous, and (b) it is unlikely that two clients will ask the same question
  • This has obvious scalability impacts for logs
  • In addition, caches like the DNS one that has been proposed provide very little privacy benefit

The specification of log operations should specify that a log is required to
maintain only the two items noted above. Endpoints for accessing the log should
reflect this requirement. I think the primary change here is that the
"Retrieve... by Leaf Hash" endpoints need to return an inclusion proof to a head
of the log's choice. Clients can then either cache tree heads or
retrieve consistency to a tree head they like better.

Change History (5)

comment:1 Changed 5 years ago by rob.stradling@…

  • Component changed from client-behavior to to-be-decided

comment:2 Changed 5 years ago by eranm@…

Related random thought:
If get-proof-by-hash / get-all-by-hash was modified to return a list of TransItems?, then it'd be possible to limit the set of artifacts that the log produces.

Rather than providing an inclusion proof to the tree size provided by the user, the log could provide an inclusion proof to the STH that covers the desired entry, and then a chain of consistency proofs between that STH and following STHs, up to the tree size provided by the user.

comment:3 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis
  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…
  • Status changed from new to assigned

I think that the protocol should enable minimizing the number of artifacts, but not force it.
Given that STH issuance frequency is already limited, that allows logs to produce a limited number of consistency proofs.
As TransItems? can be bundled, a "chain" of consistency proofs between STHs can already be provided to clients. But its size would be linear in the number of STHs, while an actual consistency proof between two STHs will be shorter, or equal to, a chain of consistency proofs between intermediate STHs.

In practice, no log operator has ever complained on the difficulty of calculating inclusion and consistency proofs on-the-fly (that's never a part we ran into difficulty implementing).

My suggestions:

  • Outline how a log may limit the artifacts it produces.
  • Change some of the HTTP endpoints to return a TransItemList? rather than a TransItem? to accommodate a collection of inclusion/consistency proofs and an STH.

comment:4 Changed 5 years ago by eranm@…

  • Milestone set to review

The 2nd suggestion was implemented by Rob in https://github.com/google/certificate-transparency-rfcs/pull/267

I think this is enough to defer handling the bigger idea of a "Strict CT" variant in a separate document.

Setting milestone to review for the chairs to either close this issue or move it to the 'to-be-decided' component.

comment:5 Changed 5 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.