Opened 5 years ago

Closed 5 years ago

#168 closed defect (wontfix)

Remove STH from `get-entries` response

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

Description

An STH is only meaningful to a client if (a) its consistency with prior tree
heads can be evaluated, and (b) the client can verify that other clients are
receiving the same history. So it's not really that useful for the log to
provide one unilaterally.

More importantly, though, the requirement for an STH here prevents the log from
making accessible entries that have not been incorporated under an STH. We
should allow logs to publish certificates as quickly as possible, even if STH
issuance needs to be slower.

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 benl@…

I object.

The purpose of the returned STH is to deal with skew. Say a client retrieves an STH, and then tries to get entries up to that STH, but hits a server that is lagging. The returned STH tells it what that server is capable of serving, and provides an STH that that server can definitely serve an inclusion proof for. Even if this recurs with an even more out-of-date server, the client will eventually retrieve an STH every server can honour.

On allowing logs to publish quickly, the constraint there is ordering - logs must decide an order before they can publish (at least as CT is currently specified), and once an order is decided calculating an STH is trivial, so the requirement to provide one is not a barrier.

However, I do agree this is not very well documented. It should:

a) explain why the STH is needed (and perhaps how to use it), and

b) require the STH to include any returned leaves.

As for STHs being meaningful to clients, clearly a client can request a consistency proof to another STH it holds, if it wishes, or simply ignore the STH if it is not useful.

comment:3 Changed 5 years ago by eranm@…

Committed in https://github.com/google/certificate-transparency-rfcs/commit/4e17e18ac6562d940572f86dd314935b7d003a6b, before I actually took notice of Ben's objection (apologies!).

I've followed-up with Ben out-of-band, but we haven't concluded the discussion yet, so I suggest leaving it open until we do.

comment:4 Changed 5 years ago by eranm@…

  • Milestone set to review

Reverted per Ben's objection and Andrew Ayer's objection on the list:
https://www.ietf.org/mail-archive/web/trans/current/msg02848.html

Given the justification for keeping it, suggest closing as wontfix.

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

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