Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate

From: "trans issue tracker" <[email-masked]>
Date: Tue, 03 Nov 2015 01:41:26 -0000

#78: algorithm agility discussion is inadequate

Comment (by [email-masked]):

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

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 13 Nov 2015 14:24:15 -0000

Comment (by [email-masked]):

 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.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 13 Nov 2015 14:25:04 -0000

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

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Nov 2015 12:13:40 -0500

Ben,

Section 10 of 6962-bis-10 says:

    Ifnecessary, 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. PowerPoint Presentation

---

From: Ben Laurie <[email-masked]>
Date: Mon, 16 Nov 2015 11:24:50 +0000

On Fri, 13 Nov 2015 at 17:13 Stephen Kent <[email-masked]> wrote:

> If necessary, the new log can contain existing entries from the frozen
>
> mysterious comment above).
>
I think it was more an observation that if you make the claim "log Y
contains all of log X" someone should probably check. :-) Standardising
that kind of claim seems a little pointless because there are an infinite
number of related claims (e.g. "log Y contains all of log X up to entry N"
or "log Y contains all of log X except certificates of type T") and reasons
for making them.

There is a need to make available the metadata
> what I noted above.

OK. You might want to update the ticket so we don't lose this!

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 16 Nov 2015 11:44:37 -0000

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

 what I noted above. "

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2015 14:39:03 -0500

Ben,

> contains all of log X" someone should probably check. :-) 
> Standardising that kind of claim seems a little pointless because 
> there are an infinite number of related claims (e.g. "log Y contains 
> all of log X up to entry N" or "log Y contains all of log X except 
> certificates of type T") and reasons for making them.
So the text in question should me omitted since there is no way for a 
log to make
the claim in a standard fashion? I'm OK with that change.
>     for each new log to all log clients. The issue of alg agility for
>     log metadata
>     So, I agree that this issue can be closed, if Section 10 is
>     revised to explain
>     what I noted above.
>
>
Here is suggested text for Section 10 to address this issue:

    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.