Opened 6 years ago

Closed 6 years ago

#141 closed defect (fixed)

expanding audit description

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

Description

The description of Auditing in Section 9.4 is vague and difficult to interpret -- “Auditing is taking partial information about a log as input and verifying that this information is consistent with other partial information held.” It would make sense to create a separate Auditor requirements document that could contain a more thorough description of auditing. Also, 9.4.1 to 9.4.3 could be moved to normative appendices which could then be referred to by the auditor draft.

Change History (7)

comment:1 Changed 6 years ago by paul@…

Please provide text for the current document.

comment:2 Changed 6 years ago by eranm@…

Below is a capture from the thread (by kseo):


In line with the approach of focussing 6962-bis on the log and moving the other components of CT into separate specifications, how about the following....

6962-bis:
Section 9.4. Auditing
Leaving the first paragraph as is [subject to further WG review].
Replace the 2nd, 3rd, and 4th paragraph with "See 'Certificate Transparency (CT) Requirements for Monitors and Auditors' for a detailed description of the functions performed by an Auditor."
Move Section 9.4.1 to Appendix A "Verifying an inclusion proof"
Move Section 9.4.2 to Appendix B "Verifying consistency between two STHs"
Move Section 9.4.3 to Appendix C "Verifying root hash given entries"

Certificate Transparency (CT) Requirements for Monitors and Auditors (draft submitted on 11/24/2015):
Change Section 3.1., first sentence:
From: Checking that a log is behaving correctly with regard to MMD, STH Frequency Count and Append-only property MUST be performed using the algorithms described in Sections 9.3 and 9.4 of [6962-bis]
To: Checking that a log is behaving correctly with regard to MMD, STH Frequency Count and Append-only property MUST be performed using the algorithms described in Section 9.3 and Appendices A, B, and C of 6962-bis.
Change Section 3.1, bullet 3:
From: In order to verify the append-only property, an Auditor executes the algorithm as described in Section 9.4.2 of [6962-bis].
To: In order to verify the append-only property, an Auditor executes the algorithm as described in Appendix B of [6962-bis].

comment:3 Changed 6 years ago by kent@…

The following text is offered to replace Section 9.4.

An Auditor interacts with a log to detect misbehavior of the log.
When it detects misbehavior, an Auditor notifies Monitors that have arranged for such notification. Because Browser Vendors supply log metadata in their browsers, each is expected to operate an Auditor, or to arrange to receive notifications of log misbehavior from Auditors, or both.

An Auditor detects log misbehavior by performing checks on log
entries and Signed Tree Heads (STHs). There are four log behavior properties that Auditors check:

  1. The Maximum Merge Delay (MMD)
  2. The STH Frequency Count
  3. The append-only property
  4. The consistency of the log view presented to all query sources

The first three of these checks are easily performed using existing log interfaces and log metadata, employing algorithms described in Appendices A, B, and C. The last check is more difficult to perform because it requires a way to share log responses among a set of CT elements, perhaps including browsers, web sites, Monitors, and Auditors, e.g., so-called gossiping. A comprehensive specification of Auditor requirements will be provided in a document to be published later.

comment:4 Changed 6 years ago by eranm@…

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

From issue #134 which I've just merged to this one:
"Section 12 says that TLS clients can use logs and SCTs to reduce the likelihood that they will accept misissued [sic] certificates. Since direct access to a log to acquire an inclusion proof is viewed as bad from a privacy perspective, it’s not clear what sort of log access by a client is being suggested here. This needs to be clarified, or just removed."

Point out there are privacy implications of clients directly communicating with logs, which the use of proxies can alleviate.

comment:5 Changed 6 years ago by eranm@…

Out for review in the (aptly numbered!) PR:
https://github.com/google/certificate-transparency-rfcs/pull/141

Note:

  • The Security Considerations section had some text about client privacy. I've added that clients can use proxies.
  • I have used the list of behaviours to check.
  • I've omitted some of the suggested text as was suggested 3 months ago, since then a reference to the threat analysis document was added and the security considerations section expanded.

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