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

From: [email-masked]
Date: Wed, 03 Jun 2015 14:00:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Public Notary Transparency  Working Group of the IETF.

        Title           : Threat Analysis for Certificate Transparency
        Author          : Stephen Kent
	Filename        : draft-ietf-trans-threat-analysis-00.txt
	Pages           : 18
	Date            : 2015-06-02

Abstract:
   This document describes a threat model for the Web PKI context in
   which security mechanisms to detect mis-issuance of web site
   certificates will be developed. The threat model covers both
   syntactic and semantic mis-issuance, using a taxonomy of threats
   starting with whether the mis-issuance was done by the CA
   maliciously or not; then whether or not the certificate was logged;
   and then whether the log(s) or monitor(s) are benign or malicious,
   whether the certificate subject is self-monitoring and whether a
   client is doing any checks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Jun 2015 13:21:56 -0800

The initial draft of the threat analysis document is out.
Please give it a careful read and post comments to the mailing
list.

Steve, if you could highlight issues that need particular
attention, that can get working group discussion off to a
strong start.

Melinda

-------- Forwarded Message --------
Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt
Date: Wed, 03 Jun 2015 14:00:30 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Public Notary Transparency  Working
Group of the IETF.

Abstract:

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

---

From: Rick Andrews <[email-masked]>
Date: Wed, 3 Jun 2015 16:44:04 -0700

Stephen,

2.2.2. Certificate not logged

   Because the CA is presumed malicious, it may choose to not submit a
   (pre-)certificate to a log. This means there is no SCT for the
   certificate.
  ...
2.2.2.1. Self-monitoring Subject

   A Subject performing self-monitoring will be able to detect the lack
   of SCT and notify the CA about the bogus certificate and request
   revocation. 

[Rick] Since the certificate is not logged, how will the self-monitoring
Subject detect the lack of SCT? The CA could mis-issue the cert but not send
it to the Subject. You need a Careful Browser detecting the lack of SCTs and
notifying the Subject for the Subject to be aware of this case. Likewise, I
think this sentence in 2.2.2.2 is incorrect: "If, when an SCT is not
provided, clients do not reject certificates and do not notify the CA or the
Subject, this form of mis-issuance will succeed unless the Subject is
self-monitoring (See 2.2.2.1 and Note 3.)"

3.1. Non-malicious Web PKI CA context

   This section analyzes the scenario in which the CA has no intent to
   issue a syntactically incorrect certificate. Throughout the
   remainder of this document we refer to a syntactically incorrect
   certificate as ''erroneous''.
[Rick] In the sections below, you also refer to certificates as "malformed".
I think "erroneous" could/should be used in those cases instead of
"malformed".

3.1.1.1. Benign log

   ...
    . If a (pre-)certificate is submitted by a third party, that party
      might contact the Subject or the issuing CA, but because the
      party is not the Subject of the certificate it is not clear how
      the CA will respond.
[Rick] I think you should remove "(pre-)", because pre-certificates cannot
be submitted by third parties, only by the CA.

3.1.2. Certificate not logged

   If a CA does not submit a certificate to a log, there can be no
   syntactic checking by the log. Detection of syntactic errors will
   depend on Subjects or Monitors performing the requisite checks.
[Rick] Detection could also be done by Careful Browsers (though I agree with
your caveat in 3.1.1.4). If you think that Careful Browsers should be added
to this Section, then they should also be added to 3.2.1.3. But I'm guessing
you intentionally didn't add Careful Browsers because to date, any checking
they have performed generally did not result in notification to Subjects or
Issuing CAs. So I'm ok if you leave them out of both Sections.

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, June 03, 2015 2:22 PM
To: [email-masked]
Cc: Stephen Kent
Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt

The initial draft of the threat analysis document is out.
Please give it a careful read and post comments to the mailing list.

Steve, if you could highlight issues that need particular attention, that
can get working group discussion off to a strong start.

Melinda

-------- Forwarded Message --------
Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt
Date: Wed, 03 Jun 2015 14:00:30 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Public Notary Transparency  Working Group
of the IETF.

Abstract:

---

From: Matt Palmer <[email-masked]>
Date: Thu, 4 Jun 2015 11:59:18 +1000

A good enumeration of the threat space.  My thoughts:

> 2.1.1.2. Malicious or conspiring log
>
>   In this case, the bogus (pre-)certificate has been submitted to one
>   or more logs that are either simply malicious or are conspiring with
>   the attacker. It is assumed that the logs issue SCTs (in an attempt
>   to fool browsers and/or Monitors). In this context, a log probably
>   will suppress a bogus certificate log entry. (This case encompasses
>   the scenario in which a log creates an entry for the certificate but
>   reports it selectively.)

Do you have any thoughts on what a "simply malicious" log might look like,
behaviourally speaking?  Is there a way to differentiate, from the outside,
whether a log is "simply malicious" or "conspiring"?  Do we even care that
there's a difference?

I wonder if it would be clearer to stick to observed behaviour, rather than
motivation?  So, rather than talking about a "simply malicious" or
"conspiring" log, say instead something like, "a log which does not
faithfully report all submitted entries, and/or presents different views of
the log to different observers".

>   Note that a malicious log also could create and report entries for
>   bogus certificates that have not been issued by the indicated CA.
>   These could cause the Monitor to report non-existent semantic
>   problems to the Subject who would in turn report them to the
>   (apparently) issuing CA. This might cause the CA to do needless
>   investigative work or perhaps incorrectly revoke and re-issue the
>   Subject's certificate.

How is a malicious log going to be able to report bogus certificates?  The
closest a malicious log could come is to whack together a cert chain that
has the same issuer names, etc, but that won't validate to the CA's *actual*
root certificate.  Is the point of this section, then, to indicate that
reporters of bogus certificates (or the CAs that receive them) should
validate the cert chain before taking action?

>From Note 5:

>   Absent a  ''gossip'' mechanism that enables Monitors to verify that
>   data from logs are reported in a consistent fashion, CT cannot claim
>   to provide protection against logs that are malicious or may
>   conspire with, or are victims of, attackers effecting certificate
>   mis-issuance. Developing such a mechanism is not easy. The mechanism
>   SHOULD protect the privacy of users (with respect to which web sites
>   they visit). It needs to scale to accommodate a potentially large
>   number of self-monitoring Subjects and a vast number of browsers (if
>   browsers are part of the mechanism). Even when a gossip mechanism is
>   defined, it will be necessary to describe how the CT system will
>   deal with a mis-behaving or compromised log. For example, will there
>   be a mechanism to alert all TLS clients to reject SCTs issued by
>   such a log? Absent a description of a mitigation strategy to deal
>   with mis-behaving or compromised logs, CT cannot ensure detection of
>   mis-issuance in a wide range of scenarios.

This doesn't seem so much an issue of threat model, as it is a commentary on
the current state of CT, and I don't think it belongs in this document.

- Matt

---

From: Stephen Kent <[email-masked]>
Date: Thu, 04 Jun 2015 12:10:38 -0400

Rick,

Thanks for reading the doc and providing comments.

> self-monitoring (See 2.2.2.1 and Note 3.)"
You're right. A self-monitoring Subject can detect a cert issued to it by
lacking an SCT, and complain to the CA, even if the cert is not logged.
(The Subject received the cert from the CA, so it has a copy and thus can
detect the absence of an SCT). But, a bogus cert would not be delivered
to the (legitimate) Subject, and thus the text above is wrong. Sorry 
'bout that.

> I think "erroneous" could/should be used in those cases instead of
Good catch. We'll make that change.
> be submitted by third parties, only by the CA.
OK, we'll remove "(pre-)".
> Issuing CAs. So I'm ok if you leave them out of both Sections.
Your interpretation is right, but I should probably include more 
explicit text here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 04 Jun 2015 12:13:47 -0400

Matt,

Thanks for the review and comments.

> whether a log is "simply malicious" or "conspiring"?  Do we even care that
probably not. we'll avoid making the distinction in the next rev.
> the log to different observers".
the text above seems like a good way to characterize bad log behavior.
we will still include comments about motivation (that's a common aspect
of a threat model), but I agree that externally observed behavior is the 
best
way to characterize this.
> validate the cert chain before taking action?
good point. There has been some ambiguity about whether every log will 
always
verify complete cert chains to one of the roots it accepts, in part of the
question of what level of cert path processing one can expect of a log. 
If we're clear
that (good) logs will do this, always, then creating a bogus log entry 
for a cert
will mark a log as misbehaving. In that case, checking the cert chain for a
log entry will detect such misbehavior. We'll add text to this end. Thanks.
> the current state of CT, and I don't think it belongs in this document.
I agree that this note is not in the same style as most of the rest of the
analysis. However, I am concerned that we don't have agreement on how a 
gossip
mechanism can work, while meeting legitimate privacy concerns and the larger
goals ascribed to it. So I think it's appropriate to retain this note 
for now,
as a reminder of what needs to be addressed as part of the overall CT 
architecture.
I have analogous comments, elsewhere in the doc, that mention the issue of
the role of browsers in CT and the problem of incremental deployment. 
The same
arguments probably apply to those comments.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 08 Jun 2015 10:07:51 -0400

Melinda,
> attention, that can get working group discussion off to a

the comments I received from Rob and Matt represent the sort of feedback I'm
looking for, e.g., terminology and definitions, specific cases that may
be erroneously stated, etc.

We'll reissue the doc with edits based on feedback in another week or 
so.  I hope
to include an ASCII art diagram of the system, derived from DKG's nice 
slides
from IETF 92.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 08 Jun 2015 15:11:50 +0100

On 08/06/15 15:07, Stephen Kent wrote:
> the comments I received from Rob

s/Rob/Rick/

> and Matt represent the sort of feedback I'm

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Mehner, Carl" <[email-masked]>
Date: Thu, 18 Jun 2015 20:00:21 +0000

Hello Stephen, thanks for writing this up. I only had a few comments (first grammatical/flow, then on the content):

Is the missing the 2119 boilerplate intentional?

In the Status section, there is a missing double quote:
> work in progress."
should be
"work in progress."

I think the 'So' is extraneous here:
>1. Introduction
>Certificates are issued by CAs. So the top level differentiation in
>   this analysis is whether the CA that mis-issued a certificate did so
>   maliciously or not.

How about:
Because CAs issue certificates, the top level differentiation in this analysis is whether the CA that mis-issued a certificate did so maliciously or not.

You are missing a period at the end of the last sentence in 2.1.1.1.

There is a double comma in 2.2.1.2 (and not to get into the finer points of RFC Grammar, there is a mix of double single-quotes and single double-quotes throughout (with the count tilting higher towards the former); Was that intentional?)

There appears to be a nested note in Note 5; this strikes me as odd, but not necessarily bad.

---------------------------------------

On the subject of semantic mis-issuance in a non-malicious Web PKI Context (Section 2.1):

A non-malicious Web PKI CA may issue certificates for which it is authorized by the CA CPS yet, is unauthorized by the Subject. This is very similar to 2.2.1.1.1, except that the party receiving the certificate is "authorized" (thus not quite fitting your description of bogus). A specific case of this is where the Subject has set up a CAA record clearly stating the Subject's policy towards certificate issuance and a non-malicious CA whose CPS states that it does not respect CAA records (in accordance with CABF BRs) issues a certificate anyway. An additional example are certificates issued when validated simply using email addresses such as the live.fi [1] cert from earlier this year, or a number of other email domains as described here->[2].
If this type of per-company policy distinction ought to earn a mention in this document, I believe that it would fit under 2.1.1. Here is my suggested text:
-----BEGIN-----
2.1.1.1
> ... all clients.
The Log, when receiving a recently signed pre-certificate SHOULD assist in detection of bogus certificates by checking CAA records [rfc6844] and sending a report to the URL as specified in the iodef property.
> ... If a bogus ...

2.1.1.1.2. Benign third party Monitor
...
When the Monitor receives a recently signed pre-certificate it MAY then check the CAA [rfc6844] record and send a report to the URL as specified in the iodef property. A Monitor MAY also check certificates for compliance with the HPKP header [rfc7469] of a Subject site or browser HPKP headers, mismatches SHOULD be reported to the Subject, if the Subject has a relationship with the Monitor, or as specified in the report-uri directive of the HPKP header.
-----END-----

I put the CAA validation on the log more strongly than the monitor because individual logs ought to be getting the SCTs right before the time of issuance (in a matter of seconds or minutes) rather than such a time as when a Monitor asks which may be at a much later time (e.g. "recently signed").

Alternatively, these additional checks for semantic correctness may belong better in the set of kent-trans-*-validation-cert-checks documents? Perhaps in new text as section 3.3?

Slightly off topic, but since it's referenced in this threat doc:
draft-kent-trans-domain-validation-cert-checks-00 2.1.6.B refers to section 9.2.6 of the CABF-DV BRv1.2.3; such a section of the BRs does not exist.

[1] ars.to/1Ftrljf || http://arstechnica.com/security/2015/03/man-who-obtained-windows-live-cert-said-his-warnings-went-unanswered
[2] https://www.cem.me/papers/emailcerts.html

> Sent: Wednesday, June 03, 2015 4:22 PM
> To: [email-masked]
> Cc: Stephen Kent

---

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

Carl,

thanks for the review and comments. responses inline below.

Steve
> Is the missing the 2119 boilerplate intentional?
no, fixed.
> In the Status section, there is a missing double quote:
fixed.
> Because CAs issue certificates, the top level differentiation in this analysis is whether the CA that mis-issued a certificate did so maliciously or not.
done
> You are missing a period at the end of the last sentence in 2.1.1.1.
fixed.
> There is a double comma in 2.2.1.2 (and not to get into the finer points of RFC Grammar, there is a mix of double single-quotes and single double-quotes throughout (with the count tilting higher to…
not intentional, fixed.
> There appears to be a nested note in Note 5; this strikes me as odd, but not necessarily bad.
fixed.
we'll have to think more about our examples. I'm not sure that 6844 has 
gained enough traction to
cite it here, but I'll defer to others on this issue.
> When the Monitor receives a recently signed pre-certificate it MAY then check the CAA [rfc6844] record and send a report to the URL as specified in the iodef property. A Monitor MAY also check cert…
I think the cert pinning checks are good ones to add as additional 
actions by a Monitor.
We'll include them in a future rev.
> I put the CAA validation on the log more strongly than the monitor because individual logs ought to be getting the SCTs right before the time of issuance (in a matter of seconds or minutes) rather…
if CAA records are widely used, then I agree with your prioritization, 
but ???
> Alternatively, these additional checks for semantic correctness may belong better in the set of kent-trans-*-validation-cert-checks documents? Perhaps in new text as section 3.3?
those docs try to enumerate the checks required by the DV and EV docs. 
these added checks are
not mentioned in those CABF specs, so I think it will be better to 
consider adding text about
cert pinning (and, maybe, CAA records) to this doc instead.
> draft-kent-trans-domain-validation-cert-checks-00 2.1.6.B refers to section 9.2.6 of the CABF-DV BRv1.2.3; such a section of the BRs does not exist.
Whoops. we'll have to fix that next time, thanks for the note.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 22 Jun 2015 21:53:09 +0100

On 22/06/15 21:12, Stephen Kent wrote:
<snip>
>> The Log, when receiving a recently signed pre-certificate SHOULD
>> assist in detection of bogus certificates by checking CAA records
>> [rfc6844] and sending a report to the URL as specified in the iodef
>> property.
> gained enough traction to cite it here, but I'll defer to others on
> this issue.
<snip>
> if CAA records are widely used, then I agree with your prioritization,

We've been doing CAA checks on all server cert requests for the last 
couple of months.  So far we've only encountered CAA records for 2 
domains, both of which belong to us!

So I think it's fair to say that CAA records are not yet widely used!

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jun 2015 09:40:27 -0400

Rob,

Thanks for the feedback based on real world observables.

Steve