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

[Ben Laurie <[e-mail]>]

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

> 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.
>

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.


> Steve
> > #96: Metadata: Should it be dynamic?
> >
> > Changes (by [e-mail]):
> >
> >   * 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.
> >
>
>