Subject: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic?

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 08:54:27 -0000

#96: Metadata: Should it be dynamic?

 Logs could advertise parts of the metadata (for example, the MMD) on a
 well-known location, sign it and have clients fetch it prior to other
 requests from the log.
 This means certain parameters could change frequently and logs would know
 exactly how clients should behave when metadata changes.
 The downside is that we would have to consider each piece of metadata and
 the implications of allowing it to change dynamically. For example, if the
 log is allowed to dynamically change the MMD, what happens to STHs issued
 "at the seams" ? Does the old MMD apply for them? the new one?

 *not* advertising parts of the metadata directly by the logs themselves
 mean logs have no way of knowing which version of the metadata clients
 have (as it would depend on external update mechanisms such as browser
 updates).

 A way to prevent this uncertainty is to declare the metadata immutable -
 i.e. a log roll-over would be necessary to change any of the log's
 parameters.

-- 
-------------------------+-------------------------------------------------
 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/96>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 09:06:12 -0000

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 We've already discussed this, I feel sure, and the general point is that
 allowing logs to manipulate their own metadata is dangerous, as you state.
 That's why the I-D says its distribution is out of scope.

 As you know, in practice, Chrome defines its own log metadata, and that is
 what clients use. I imagine this will be the general pattern.

 I propose this is resolved as wontfix.

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

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Jul 2015 11:40:04 +0200

There are two types of log metadata. Some if the data is analogous to 
trust anchor
info and thus distributing it to TLS clients using the same (not 
standardized) browser
vendor mechanisms makes sense. (This does, though, raise an issue about 
how non-browser
client acquire this info; Monitors and Auditors are not necessarily 
products of vendors
and thus there may not be the same infrastructure to distribute this 
sort of data.)

Other log metadata (e.g., MMD and STH frequency) is less like trust 
anchor info and
it could be distributed by having a signed, time-stamped data structure 
posted at a known
location associated with the log. A potential benefit of this model is 
that a log operator
can know that if it changes these parameters, all clients are able to 
acquire the new info
at the same time. If one relies on an unspecified distribution mechanism 
for these parameters,
a log operator cannot know when all clients have received the new info. 
That uncertainty
might cause operational problems. So, the title for this issuer is not 
really whether ALL
metadata should be dynamic, but rather whether some of it should be.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jul 2015 11:44:19 +0000

On Thu, 23 Jul 2015 at 10:40 Stephen Kent <[email-masked]> wrote:

> location associated with the log.

A potential benefit of this model is
> metadata should be dynamic, but rather whether some of it should be.

MMD and STH frequency are parameters that cannot be freely varied and still
allow useful operation of the system. It does not seem to me that it would
ever be appropriate to allow logs to unilaterally change them - that's
precisely why they're part of the metadata and not data that can be
retrieved from the log.

Perhaps the simplest thing to do is note that changing metadata is also
implementation dependent (as well as distribution) and out of scope?

Obviously if something doesn't belong in metadata at all, that's a
different matter.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jul 2015 17:30:15 +0200

Ben,

Based on further discussion during the WG meeting I think all
of the metadata should be described as immutable for a log (instance),
expect for the final STH. That way it will be clear to readers that
if a log wants to change any of these values, a new log MUST be created.

Steve

>
>
> On Thu, 23 Jul 2015 at 10:40 Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> MMD and STH frequency are parameters that cannot be freely varied and 
> still allow useful operation of the system. It does not seem to me 
> that it would ever be appropriate to allow logs to unilaterally change 
> them - that's precisely why they're part of the metadata and not data 
> that can be retrieved from the log.
>
> Perhaps the simplest thing to do is note that changing metadata is 
> also implementation dependent (as well as distribution) and out of scope?
>
>     > Changes (by [email-masked] <mailto:[email-masked]>):
>     >
>     >   * milestone:   => review
>     >
>     >
>     > Comment:
>     >

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Jul 2015 15:38:25 +0000

> if a log wants to change any of these values, a new log MUST be created.

Agree.

(I know! Twice in 24 hours!).

>
> Steve
>
>
>
>
>  On Thu, 23 Jul 2015 at 10:40 Stephen Kent < <[email-masked]>[email-masked]>
> wrote:
>
> still allow useful operation of the system. It does not seem to me that it
> would ever be appropriate to allow logs to unilaterally change them -
> that's precisely why they're part of the metadata and not data that can be
> retrieved from the log.
>