Opened 6 years ago

Closed 6 years ago

#128 closed defect (fixed)

section 5 over-claims the properties of an STH

Reported by: david@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

From https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10#section-5:

Periodically, the log MUST append all its new entries to its Merkle
Tree and sign the root of the tree. This provides auditable evidence
that the log kept all its promises.

I think the second sentence here over-claims the security properties provided by the STHs. Publication of an STH enables a set of checks that may enable others to detect log misbehavior, but the gossip draft shows that such detection requires a lot of mechanisms beyond just STH generation.

Change History (7)

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

If the second sentence was "This proves that the log kept all its promises", then I would understand and agree with your comment. But that's not what it says.

It says "provides auditable evidence".

What security property of "just STH generation" do you think we're claiming?

comment:2 Changed 6 years ago by eranm@…

If I understand correctly, the point is that the STH is "auditable evidence" only for clients that hold SCTs issued prior to the issuance of that particular STH.
That is, it is not possible a single entity observing the log to verify that the "log kept all its promises" because it may not have all the promises (i.e. SCTs) that the log has made.

David, is that your point?

comment:3 follow-up: Changed 6 years ago by rob.stradling@…

Should we qualify the statement then? e.g. something like...
"This provides auditable evidence that the log kept all its observed promises."

Or could we just remove that entire sentence?

comment:4 in reply to: ↑ 3 ; follow-up: Changed 6 years ago by david@…

Replying to eranm@…:

If I understand correctly, the point is that the STH is "auditable evidence" only for clients that hold SCTs issued prior to the issuance of that particular STH.
That is, it is not possible a single entity observing the log to verify that the "log kept all its promises" because it may not have all the promises (i.e. SCTs) that the log has made.

David, is that your point?

That's part of my point. The other part is that the single entity may not have all the STHs that the log has made, so the STHs it observes do not necessarily provide any evidence that the log is not returning different views to different observers.

Replying to rob.stradling@…:

Should we qualify the statement then? e.g. something like...
"This provides auditable evidence that the log kept all its observed promises."

What do you mean by "observed promises"?

Or could we just remove that entire sentence?

That would be a simple way to address this. If you want to keep a similar statement though, you could take a look at https://tools.ietf.org/html/draft-kent-trans-architecture-01#section-3.6 and describe STH generation's role in those 4 checks.

comment:5 in reply to: ↑ 4 Changed 6 years ago by rob.stradling@…

Replying to david@…:

Replying to rob.stradling@…:

Should we qualify the statement then? e.g. something like...
"This provides auditable evidence that the log kept all its observed promises."

What do you mean by "observed promises"?

I mean the SCTs that have been observed by an auditor that is auditing the "auditable evidence".
But I concede that "all...observed" is unclear. It could be taken to mean all SCTs that have been observed by anyone (rather than all SCTs observed by one particular auditor).

Or could we just remove that entire sentence?

That would be a simple way to address this.

I've proposed that change here:
https://github.com/google/certificate-transparency-rfcs/pull/98

If you want to keep a similar statement though, you could take a look at https://tools.ietf.org/html/draft-kent-trans-architecture-01#section-3.6 and describe STH generation's role in those 4 checks.

I think that that level of detail of the auditing function would be out of place in a section that is intended to introduce log requirements.

comment:6 Changed 6 years ago by rob.stradling@…

  • Milestone set to review

comment:7 Changed 6 years ago by melinda.shore@…

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