Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem

From: "trans issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2016 15:08:22 -0000

#118: Monitor function description problem

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

Comment:

 Is the problem here that the term 'monitoring' means something different
 in this context, making the introduction and Section 9.3. inconsistent?
 I can suggest a few resolutions:
 (1) Replacing the word 'monitor' in the introduction with 'watch'.
 (2) Modify the Monitor section to indicate a monitor can either ensure
 logs behave correctly, watch for certificates of interest or do both.

 From what Steve says, it seems the term 'monitor' in CT context is used to
 refer both to monitors that audit logs and ones that just watch for
 certificates of interest, so option (2) seems more reasonable to me.

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

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:3>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2016 15:10:25 -0000

Comment (by [email-masked]):

 Out for review in https://github.com/google/certificate-transparency-
 rfcs/pull/136

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:50:50 -0400

Eran,

> Changes ([email-masked]):
>
>   * owner:[email-masked]  =>[email-masked]
>
>
> Comment:
>
In most prior versions of 6962-bis, Auditing has focused on detecting
mis-behaving logs. Why not stick with that characterization of the 
function?
Your suggestion #2 above seems to make Monitors overlap with Auditors,
rather than having simple, distinct definitions for them.

Let's   say that a Monitor observes an enumerated set of logs for certs 
of interest,
so that it can inform Subjects if there is evidence that a bogus cert has
been logged (relative to the Subject in question).

An Auditor observes an enumerated set of losg to detect log misbehavior.

These are roughly the ways that draft-kent-trans-monitor-auditor-00.txt
characterizes the two functions.

Steve

---

From: Eran Messeri <[email-masked]>
Date: Thu, 17 Mar 2016 12:19:45 +0000

On Wed, Mar 16, 2016 at 5:50 PM, Stephen Kent <[email-masked]> wrote:

> Let's   say that a Monitor observes an enumerated set of logs for certs of
> interest,
There may be a misunderstanding here: in 6962-bis the Auditor entity was
replaced with an auditing role, that different entities (a Monitor being
one) can take.
Section 9.4. of draft 12 explains how monitors can audit and how TLS
clients can, while section 9.3., about Monitors, describes the process a
Monitor should use to audit.

I believe that change was partly made thanks to your feedback that the
Monitor and Auditor entities have some overlap and the distinction wasn't
quite clear.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 18 Mar 2016 14:12:05 -0000

* milestone:   => review

Comment:

 Landed in https://github.com/google/certificate-transparency-
 rfcs/commit/7120d1867d40522f65c8fe19191388c6b88560c7

 Priority:  major         |   Milestone:  review

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Mar 2016 11:09:01 -0400

Eran,

> There may be a misunderstanding here: in 6962-bis the Auditor entity 
> was replaced with an auditing role, that different entities (a Monitor 
> being one) can take.
I recall when you and your co-authors unilaterally decided that there 
would be no Auditor
as a separate CT element. Both DKG and I complained about that decision, 
to no avail.
However, let's compromise and consider both Monitors and Auditors to be 
functions or roles.
so that readers do not assume that these roles must be implemented by 
separate systems. OK?

I object to the current wording in the Monitor description because it 
mandates that a Monitor
perform auditing, and does not mandate that it perform what I see as the 
the basic Monitor role.
As currently described, there is no mandated role in CT that observes 
logs looking for possibly
bogus certs on behalf of Subjects. This strikes me as a serious omission.

> clients can, while section 9.3., about Monitors, describes the process 
> a Monitor should use to audit.
Rob Stradling reviewed my Monitor doc a few month ago and agreed with 
the description,
noting that his implementation of a Monitor also did not perform 
auditing. (It just
observes logs to detect certs of "interest." I mentioned this on the 
TRANS list as part
of why I believe that it is inappropriate to mandate any Auditor 
functions as
part of the Monitor role. again, this feedback seems to have been ignored.
> Monitor and Auditor entities have some overlap and the distinction 
> wasn't quite clear.
The distinction was not clear, but this revised set of definitions is 
worse, i.e.,
it does not require a Monitor to watch for potentially bogus certs.

Steve

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 18 Mar 2016 19:23:16 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

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

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

---

From: Eran Messeri <[email-masked]>
Date: Mon, 21 Mar 2016 11:08:27 +0000

> so that readers do not assume that these roles must be implemented by
Sounds good! FWIW the reason to remove Auditor as a separate CT element is
that it confused people in 6962-bis and whoever implemented "log clients
that are not just TLS clients" always called them monitors.

> As currently described, there is no mandated role in CT that observes logs
> looking for possibly
> Rob Stradling reviewed my Monitor doc a few month ago and agreed with the
> description,
> noting that his implementation of a Monitor also did not perform auditing.
> (It just
> observes logs to detect certs of "interest." I mentioned this on the TRANS
> list as part
> of why I believe that it is inappropriate to mandate any Auditor functions
> as

This is very valid feedback - the change I've pushed last week (and should
be in a draft 13 I'll publish later today) takes it into account: I've
clarified that a Monitor can do each of these actions (or both) and states
that the rest of the section describes algorithms how to do it, in addition
to saying clients can audit as well (and describe the algorithms they can
use for that).

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Mar 2016 11:32:57 -0400

Eran,

Thanks for being willing to make changes to the Monitor description.

the next text is better, but, IMHO it still has problems. For example

    Monitors watch logs to check that they behave correctly, for
    certificates of interest, or both.  For example, a monitor may be
    configured to report on all certificates that apply to a specific
    domain name when fetching new entries for consistency validation.

    A monitor needs to, at least, inspect every new entry in each log it
    watches.

The first sentence is very confusing. I still think the primary job of a 
monitor
is to observe logs for cert "of interest" not to detect log misbehavior. 
The latter
function is the focus of auditing. Why make one (of 4) types of log 
misbehavior a
function for Monitors? Why not focus exclusively on log observation? The
characterization of monitoring in the introduction (page 4) says:

*   Those who are concerned about misissuance can monitor the logs,
    asking them regularly for all new entries, and can thus check whether
    domains they are responsible for have had certificates issued that
    they did not expect.*

Thus the changes I have requested are consistent with what the doc 
already says.

The "for example" sentence also isn't great from a standards 
perspective. First, it's
just an example, and "domain" isn't defined. Also it again focuses on 
consistentcy
validation for a log instead of protecting Subjects by detecting issuance of
bogus certs.

I cold go on, but I think you get the sense of my concerns.

Steve