Subject: Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys?

From: "trans issue tracker" <[email-masked]>
Date: Tue, 09 May 2017 11:21:59 -0000

#170: Allow for separate SCT and STH keys?
-------------------------+-----------------------
 Reporter:  rlb@…        |       Owner:  eranm@…
     Type:  defect       |      Status:  assigned
 Priority:  major        |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-----------------------
Changes (by eranm@…):

 * owner:  draft-ietf-trans-rfc6962-bis@… => eranm@…
 * status:  new => assigned
 * component:  to-be-decided => rfc6962-bis
 * milestone:   => review

Comment:

 I agree with the analysis that the keys used for signing SCTs and STHs do
 not have to be the same.
 However, I'm not sure there's value in allowing that, and it does incur
 added cost.

 In theory it allows for separate security domains between the front-end
 and the signer. But I’d argue that as a log operator, that doesn’t buy us
 much because the signer is not tied to a single datacenter / HSM. The
 signing "role" migrates between jobs at different datacenters (for
 resiliency). Additionally, the key separation would be completely
 unnecessary if we ever build a log with immediate incorporation, where a
 signer is not necessary since sequencing of entries (and STH production)
 is done for each submission.
 As Richard points out, compromise of either keys has the same
 implications.

 It does complicates the client implementation: Client now has to keep two
 keys for the log instead of one.

 So I suggest closing this as wontfix.  We can mention the option somewhere
 in the document, but currently I don't see the need.

--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/170#comment:2>
Public Notary Transparency  Wiki <https://trac.ietf.org/trac/trans>
My example project

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 09 May 2017 13:32:36 -0000

Comment (by linus@…):

 As a log implementer and log operator I'd like to express support for the
 idea of using separate keys for signing SCTs and STHs.

 In an architecture where the log owner can delegate //some// power to
 other organisations for operating frontend nodes by allowing frontend
 nodes to sign SCTs but not STHs, this would lower the risk of "full
 takeover" of a log. While there certainly are attacks that can be
 performed by an adversary capable of producing either SCTs //or// STHs I
 think there are also attacks that require that //both// SCTs and STHs can
 be signed.

 Note that the threat is not limited to an adversary getting hold of a copy
 of key material but also includes the capability of having SCTs and STHs
 signed by a signing service. I mention this because the design and
 implementation of such signing services would be less complex if they
 didn't have to deal with multiple keys and roles for these keys.

 While I disagree with the stated lack of benefit I do agree that there is
 a cost in client implementation and also in overall complexity of the
 system. I think that the benefit outweigh the cost but would like to hear
 other peoples view on this, especially CT client implementors.

--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/170#comment:3>
Public Notary Transparency  Wiki <https://trac.ietf.org/trac/trans>
My example project

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 10 May 2017 12:53:16 -0000

Comment (by linus@…):

 From
 https://mailarchive.ietf.org/arch/msg/trans/slDhAuH3WW1AvX9wManfViWe4fg:
 "I withdraw my support for separate keys for signing SCT's and STH's and
 will update #170 to reflect this."

--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/170#comment:4>
Public Notary Transparency  Wiki <https://trac.ietf.org/trac/trans>
My example project

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 11 May 2017 20:44:45 -0000

#170: Allow for separate SCT and STH keys?
-------------------------+----------------------
 Reporter:  rlb@…        |       Owner:  eranm@…
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+----------------------
Changes (by melinda.shore@…):

 * status:  assigned => closed
 * resolution:   => wontfix

--
Ticket URL: <https://trac.ietf.org/trac/trans/ticket/170#comment:5>
Public Notary Transparency  Wiki <https://trac.ietf.org/trac/trans>
My example project