Opened 7 years ago

Closed 6 years ago

#78 closed defect (fixed)

algorithm agility discussion is inadequate

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

Description

Section 6 does not provide an adequate description of how algorithm agility is achieved. It refers to Section 5.1, which defines log metadata. See other documents, e.g., RFC 6916, that describe algorithm agility for a security system as an illustration of the sort of description that is appropriate.

Change History (12)

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

  • Component changed from client-behavior to rfc6962-bis

comment:2 Changed 7 years ago by benl@…

I am not clear what you are asking for. I cannot provide a long detailed plan for migrating from one log to another because the plan is as stated: freeze one log, start another one.

comment:3 Changed 7 years ago by kent@…

The current, very brief description does not discuss a number of issues of
how a planned algorithm transition takes place. For example, if a log
operator wants to move to a new signature algorithm, it needs to create the new
metadata that points to the new log, including a new URL, new algorithm
identifiers and new keys. The means by which this metadata is distributed is not
specified, but it seems likely that the browser-vendor channel for distribution of this
metadata will take a little while. So, there is a need for guidance to a log operator
as to how to deal with the unknown delays for this metadata to become
widely available. There is also the question of when the old log is frozen relative to the new
log, and how this relates to the various types of log clients (CAs vs.
browsers vs. Monitors). For example, do CAs now need to get SCTs for certs from both the old and
new logs to ensure continuity for SCT consumers, and if so, for how long does
this dual operation persist?

I think this is a non-trivial problem and the current text does not
address the sorts of issues noted above.

Note that the RPKI published a detailed description of how a phased
algorithm transition is to be effected for that system. That system faces a much more
difficult transition task, but the principle of documenting how a staged transition with some
established interval lengths, still seems appropriate.

comment:4 Changed 7 years ago by eranm@…

More text about algorithm agility is out for review in:
https://github.com/google/certificate-transparency-rfcs/pull/91

comment:5 Changed 7 years ago by benl@…

The problem I have with this is there's really no relationship between the old log and the new log. There is no "transition", there's just two logs, one of which is starting up and one of which is shutting down. It makes no difference whether they're operated by the same or different people, they're independent entities which have no interdependencies.

comment:6 Changed 7 years ago by benl@…

Which is also why "algorithm agility" as generally conceived doesn't seem to me to make much sense in this context.

comment:7 Changed 7 years ago by eranm@…

From discussion on the mailing list (quoting Steve Kent):
"Section 10 of 6962-bis-10 says:

If necessary, the new log can contain existing entries from the frozen log, which monitors can verify are an exact match.

To me, this suggests a connection between and old log a a new one, so
they don't seem to be completely independent, as you suggest. But, I see
you point that a new log will have new metadata and the fact that it has
any ties to the old log is largely irrelevant (other than the somewhat
mysterious comment above). There is a need to make available the metadata
for each new log to all log clients. The issue of alg agility for log metadata
is addressed via that mechanism (which seems to be unspecified).

So, I agree that this issue can be closed, if Section 10 is revised to explain
what I noted above. "

comment:8 Changed 6 years ago by eranm@…

It seems to me that the misleading text is what Steve quotes:
"If necessary, the new log can contain existing entries from the frozen log, which monitors can verify are an exact match.".

I've changed the text in my pull request to clarify that the old and new log are unrelated - that certificates in the old log that haven't expired and still require valid SCTs should be re-logged in the new log and SCTs from the new log used.

Is that adequate?

comment:9 Changed 6 years ago by eranm@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…

comment:11 Changed 6 years ago by eranm@…

Text supplied by Steve Kent, in case the current changes are not enough:
"
The term "algorithm agility" refers to mechanism and procedures that enable
use of different sets of algorithms within a protocol or system. It also often
encompasses the transition from one set of cryptographic algorithms to another,
in a fashion that avoids service disruption.

All of the cryptographic algorithms defined for use with CT are represented as log metadata. None of these algorithms can be changed for an extant log. When a new log is created the log operator MUST specify all of the cryptographic algorithms as part of the metadata for that log. This metadata MUST be made available to all log clients. For TLS clients that are web browsers, CT relies on browser vendors to convey this metadata to the clients. For all other log clients, the means of disseminating log metadata is undefined.

The set of cryptographic algorithms initially specified for CT (in RFC XXXX) will change
over time. New, standard algorithms will be published as (standards track) RFCs. Log
operators and clients will be required to support these algorithms (for new logs)
during a time frame specified by these RFCs.
"

comment:12 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.