Opened 5 years ago

Closed 5 years ago

#170 closed defect (wontfix)

Allow for separate SCT and STH keys?

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

Description

Should there be a way for a log to have separate keys for signing SCTs vs. STHs?
In principle, compromise of either is catastrophic to a log. However, given
that essentially all current log designs have a separation between the front end
(which produces SCTs) and the back end (which produces STHs), the requirement
that both be signed with the same key seems to requier sharing of the same
private key across devices, which is not a good design pattern.

This simplest way to do this would be to just declare the different keys as part
of the log metadata. You could also choose one key to be the principal one for
the log, and have an endpoint with a signed struct under that key that
specifies the keys that have been delegated to.

If we even want the option of doing this in the future, though, we'll need some
sort of key identifier in the signed structs, in addition to the log identifier.

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

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

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.

comment:3 Changed 5 years ago 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.

comment:4 Changed 5 years ago 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."

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

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