Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt

From: "Cooley, Dorothy E CIV (US)" <[email-masked]>
Date: Tue, 16 Jun 2015 18:34:30 +0000

All,

This is my first post on list ever, so be gentle :)

General:  This is actually an attack model with an analysis of detection and consequence.  Perhaps the name could be changed to reflect that.

General:  2.2’s outline should follow 2.1’s outline.  Move ‘Malicious or conspiring third party Monitor’ to section 2.2.1.3 and remove it from 2.2.1.1.3 and 2.2.1.2.1.  It may be complete either way, but it is more likely to look complete if it is symmetric.

General:  Remove the references to the Notes in Sections 2 and 3.  They will stand alone.

Section 2.1.1.1.1:  Change to:
“If a Subject is tracking the log(s) to which a certificate was submitted, and is performing self-monitoring, then it will be able to detect a bogus (pre-) certificate and request revocation. In this case, the CA will make use of the log entry, supplied by the Subject to determine the serial number of the mis-issued certificate, and investigate/revoke it.”

Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the “If there are many logs, it may not be feasible for a Subject to track all of them” a note in Section 4 (it is sort of Note 1 currently).

Section 2.1.1.1.2:  Change this in a similar manner to 2.1.1.1.1, for the same reasons.

Section 2.1.1.2.2:  How will gossiping detect this?  The Log owner issues the SCT, but doesn’t actually put the certificate into the log.  How is this detectable by gossiping?  Not like an attacker is going to submit that certificate to multiple logs.  He just wants the SCT.

Section 2.1.2:  Does the 3rd party monitor have a role in the case where the certificate isn’t logged?  Should that fact be stated?  Perhaps a sentence to that effect in Section 2.1.2.3 would be in order?

Section 2.1.2.1:  Either remove the last sentence in the parenthetical, or work it into the paragraph without the parenthetical.

Section 2.2.1.2:  Add a section on Self-monitoring Subject and a section on benign third party Monitor.

Section 2.2.1.1.3 and 2.2.1.2.1:  Combine these into Section 2.2.1.3 called malicious or conspiring third party monitor.

Section 3, Syntactic checks:  We need to think about whether this makes sense.  This paper gets much simpler w/out it.  Currently not included in rfc6962bis.

Section 4, Notes:  These are issues that will need to be addressed.  I would make a more descriptive name and keep them numbered.

Section 4, Note 1:  Make this two items.  First:  How are new logs discovered by monitors?  Second:  how does a subject know which logs the monitor is checking?

Deb Cooley

[email-masked]<mailto:[email-masked]>

410-854-6888

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Jun 2015 10:07:35 -0400

Deb,

Thanks for reading the doc and providing comments prior to our next 
planned rev.

My responses are inline below.

Steve

> General:  This is actually an attack model with an analysis of 
> detection and consequence.  Perhaps the name could be changed to 
> reflect that.
>
I agree. We'll change it for the next rev.
>
> General:  2.2’s outline should follow 2.1’s outline.  Move ‘Malicious 
> or conspiring third party Monitor’ to section 2.2.1.3 and remove it 
> from 2.2.1.1.3 and 2.2.1.2.1.  It may be complete either way, but it 
> is more likely to look complete if it is symmetric.
>
We'll try to better align the outlines between 2.1 and 2.2. But, because 
the CA assummptions
differ, it may not be possible to make the outlines completely parallel 
(without introducing
redundant sections that may make reading harder in a different way). 
We'll review the placement of 2.2.1.1.3 and 2.2.1.2.1 in the context of 
outline realignment.
> General:  Remove the references to the Notes in Sections 2 and 3.  
do you mean the notes will stand alone? I agree that the notes can stand 
alone, but I worry that
folks reading the sections that now contain those forward references may 
not tie them back to
the relevant sections without the forward references.
> “If a Subject is tracking the log(s) to which a certificate was 
> submitted, and is performing self-monitoring, then it will be able to 
> detect a bogus (pre-) certificate and request revocation. In this 
> case, the CA will make use of the log entry, supplied by the Subject 
> to determine the serial number of the mis-issued certificate, and 
> investigate/revoke it.”
>
We'll make the suggested change.
>
> Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the “If 
> there are many logs, it may not be feasible for a Subject to track all 
> of them” a note in Section 4 (it is sort of Note 1 currently).
>
we can add text to state this potential problem, in the indicated 
sections. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors 
is the specific
text you cited correct. So, we'll substitute Monitor for Subject in your 
text, OK?
> Section 2.1.1.1.2:  Change this in a similar manner to 2.1.1.1.1, for 
OK.
>
> Section 2.1.1.2.2:  How will gossiping detect this?  The Log owner 
> issues the SCT, but doesn’t actually put the certificate into the 
> log.  How is this detectable by gossiping?  Not like an attacker is 
> going to submit that certificate to multiple logs.  He just wants the SCT.
>
I based this comment on the projected capabilities of a gossip 
mechanism, the details of which
are yet to be agreed upon.  I think the notion is that multiple Auditors 
query log(s) to determine
if the returned log entries and STHs represent consistent views. I'll 
try to generate some better
text here, and to discuss the Audit function in the intro, to help clarify.
>
>
> Section 2.1.2:  Does the 3rd party monitor have a role in the case 
> where the certificate isn’t logged?  Should that fact be stated?  
> Perhaps a sentence to that effect in Section 2.1.2.3 would be in order?
>
When a cert is not logged, no Monitor, even a self-monitoring Subject, 
will detect issuance of a
bogus cert based on Monitor functions. That's what this section is 
intended to convey, but we can
try to improve the wording.
>
> Section 2.1.2.1:  Either remove the last sentence in the 
> parenthetical, or work it into the paragraph without the parenthetical.
>
OK.
> Section 2.2.1.1.3 and 2.2.1.2.1:  Combine these into Section 2.2.1.3 
> called malicious or conspiring third party monitor.
>
I don't follow your comment above. it doesn't match the outline for 
section 2.1. I think
2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems 
appropriate as an enumeration
of cases under 2.2.1.1.
>
>
> Section 3, Syntactic checks:  We need to think about whether this 
> makes sense.  This paper gets much simpler w/out it. Currently not 
> included in rfc6962bis.
>
6962bis failed to define what a mis-issued cert is, even though the term 
is the focus of the
CT effort. When I asked Ben about this last year I initially thought 
that only bogus certs
(as we now define them) were mis-issued. But, Ben stated that a failure 
to adhere to the DV
or EV cert profiles would be considered mis-issuance for certs of that 
genre. I agree that
this should counted as mis-issuance, and if we intend to expand CT 
beyond Web PKI certs,
then syntactic mis-issuance is even more important. That's why we have 
two candidate syntactic
cert profiles posted, and why I proposed a mechanism to allow a 
submitter to declare what
type of cert is being submitted to a log. I also suggest that logs be 
allowed to optionally
check submitted (pre-) certs against an declared type, perform 
appropriate checks if they
can (and are willing) and record the results in the SCT.
>
> Section 4, Notes:  These are issues that will need to be addressed.  I 
> would make a more descriptive name and keep them numbered.
>
OK. We'll add more text for each note and use outline numbering for them.
>
>  Section 4, Note 1:  Make this two items.  First:  How are new logs 
> discovered by monitors?  Second:  how does a subject know which logs 
> the monitor is checking?
>
Good point. we'll do that.

---

From: "Cooley, Dorothy E CIV (US)" <[email-masked]>
Date: Fri, 19 Jun 2015 17:27:32 +0000

[debc]  I’ve cut anything that I agreed with.

[sk] do you mean the notes will stand alone? I agree that the notes can stand alone, but I worry that
folks reading the sections that now contain those forward references may not tie them back to
the relevant sections without the forward references.

[debc]  I did mean that the notes should/will stand alone.  Maybe once those notes have real section numbers it will flow better with the forward references.

[sk] we can add text to state this potential problem, in the indicated sections. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors is the specific
text you cited correct. So, we'll substitute Monitor for Subject in your text, OK?

[debc]  yes, subject or monitor will both have this problem.

[debc] not sure what happened to this one...

[sk] I don't follow your comment above. it doesn't match the outline for section 2.1. I think
2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate as an enumeration
of cases under 2.2.1.1.

[debc] no worries if this doesn’t make sense.  This is just a second comment looking to make 2.1 and 2.2 outlines the same-ish.

[sk] 6962bis failed to define what a mis-issued cert is, even though the term is the focus of the
CT effort. When I asked Ben about this last year I initially thought that only bogus certs
(as we now define them) were mis-issued. But, Ben stated that a failure to adhere to the DV
or EV cert profiles would be considered mis-issuance for certs of that genre. I agree that
this should counted as mis-issuance, and if we intend to expand CT beyond Web PKI certs,
then syntactic mis-issuance is even more important. That's why we have two candidate syntactic
cert profiles posted, and why I proposed a mechanism to allow a submitter to declare what
type of cert is being submitted to a log. I also suggest that logs be allowed to optionally
check submitted (pre-) certs against an declared type, perform appropriate checks if they
can (and are willing) and record the results in the SCT.

[debc] it will be interesting to see how this evolves.

Deb Cooley

________________________________
From: Stephen Kent [[email-masked]]
Sent: Thursday, June 18, 2015 10:07 AM
To: Cooley, Dorothy E CIV (US); [email-masked]
Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt

Deb,

Thanks for reading the doc and providing comments prior to our next planned rev.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jun 2015 16:26:43 -0400

Deb,

> [debc]  I did mean that the notes should/will stand alone. Maybe once 
> those notes have real section numbers it will flow better with the 
> forward references.
>
we have made that change.
OK.
> [debc] not sure what happened to this one...
I think we addressed that in our next rev.

Steve