Subject: [Trans] [trans] #128 (rfc6962-bis): section 5 over-claims the properties of an STH

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 02:19:01 -0000

#128: section 5 over-claims the properties of an STH

 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
 [https://tools.ietf.org/html/draft-ietf-trans-gossip-01 the gossip draft]
 shows that such detection requires a lot of mechanisms beyond just STH
 generation.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]   |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 10:41:31 -0000

Comment (by [email-masked]):

 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?

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 14:59:09 -0000

Comment (by [email-masked]):

 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?

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 15:05:04 -0000

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?

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 20:52:56 -0000

Comment (by [email-masked]):

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

 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.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:4>
trans <http://tools.ietf.org/trans/>