I have review the current draft of the threat analysis document and believe
that there are a number of issues that should be addressed before this document
is approved. Below ar ethe comments that I have on the draft:
I believe the current last call was intended to solicit comments only on the
changes made since the -012 version, since prior last calls solicited comments
on the rest of this I-D months ago. It appears that almost all of your comments
are on other parts of the document. Nonetheless, many of your comments
identified valid points that merit charges to the text, as noted in my
responses below.
- The draft discusses three categories of CAs: non-malicious, malicious, and
compromised. However, the categories are confusing due to the ways in which
these terms are used. For example, it implies that a CA is considered to be
compromised only if an attacker has stolen (purloined) a copy of the CA's
private key. It notes that "a compromised CA is essentially a malicious CA."
The text in Section 3.3 combined with the text in Section 3.1 seems to
explicitly exclude DigiNotar as being an example of a compromised CA, even
though the general agreement is that what happened to DigiNotar was a
compromise (see https://en.wikipedia.org/wiki/DigiNotar). It is unclear why
Section 3.3 is needed at all, given that Section 3.1 already addresses cases of
compromised CAs.
The primary distinction is between malicious and non-malicious CAs (Sections
3.1 and 3.2), as noted near the end of Section 1 (where the general outline for
the taxonomy is presented). Compromised CAs are nominally non-malicious, but
they act as though they were malicious, until the compromise is detected. That
motivates Section 3.3 discussing undetected compromise. I agree that there is
some overlap between 3.2 and 3.3, but I think it is helpful to explore
undetected compromise separately. I also agree that the DigiNotar case is an
example of a compromised CA, and so I will move the reference to it to Section
3.3. I also will change text in 3.3 to state that a compromise might not
require an attacker to have acquired the private key per se.
- Section 4 of the document includes a lot of text about "attacks" involving
syntactic mis-issuance, but there is nothing explain how syntactic mis-issuance
could be part of an attack. The text describes a scenario in which a malicious
CA intentionally issues a certificate that is syntactically incorrect, the
Subject of the certificate reports the problem, and the CA doesn't take action.
No explanation is provided as to how this could be part of an attack. Can't the
Subject just get a new certificate from a different CA? While it is clear that
there is a benefit to detecting syntactic mis-issuance and working to have such
errors corrected, it is not at all clear how syntactic mis-issuance could be
part of an attack. Either some explanation of how syntactic mis-issuance could
be used as part of an attack (particularly an attack in which the Subject is
not one of the attackers) or the text about "attacks" in Section 4 should be
removed.
You raise an interesting question. I originally assumed that mis-issuance
referred only to certificates that misrepresented the identity of the
certificate holder or included bogus info intended to mislead relying parties.
Several years ago I requested Ben to clarify what constituted mis-issuance. The
term was (and is still) used throughout 6962-bis without definition. (I’m
surprised that this lack of a definition for such a critical term in 6962-bis
hasn’t merited a comment from you to the authors of that document!) Ben replied
that a certificate that violated the syntax imposed by a criteria such as the
CABF would qualify as mis-issued. That’s why syntactic mis-issuance became an
element of this analysis. Violating the syntax rules imposed by such criteria
might cause processing problems for browsers that would have adverse
consequences. Perhaps what concerned Ben was the observation that, if a CA
issues a certificate not consistent with its advertised syntax criteria, that
merits detection by CT, as an example of CA misbehavior.
- Section 2 begins by saying that "A threat is defined, traditionally, as a
motivated, capable adversary." But, this is not correct, nor is it consistent
with the remainder of this draft. NISTIR 7298, for example, defines a threat as
"the potential source of an adverse event." This draft is supposed to describe
an attack model and describe threats to the Web PKI. Mis-issuance (especially
syntactic mis-issuance) does not require an attacker or a motivated, capable
adversary. Mis-issuance may be the result of carelessness, but it is still a
threat, which is why Section 4.1.1.1 discusses unintentional syntactic
mis-issuance. Given that the threat model includes unintentional mis-issuance,
Section 2 needs to be rewritten to take into account that not all threats
involve "attacks" or "a motivated, capable adversary."
The definition of threat used here has been employed for a long time, e.g., in
the U.S. DoD, decades before the publication of NISTIR 7298. Several, easily
found examples (thanks to a quick Google search) include the syllabus for
Cornell CS 5430, for MIT course 6.805, the NRC Report “Who Goes There:
Authentication Through the Lens of Privacy”, … Mis-issuance is not a threat;
it is an example of an attack. If the mis-issuance is the result of an error,
then no adversary is involved. To help clarify the first paragraph of Section
2, will be revised: “Nonetheless, it is useful to document perceived threats
against a system to provide a context for understanding attacks (even though
some attacks may be the result of errors, not threats).”
- Them second paragraph of Section 2 begins "As noted above, the goals of CT
are to deter, detect, and facilitate remediation of attacks on the web PKI."
This is incorrect. What is noted above is that "Certificate transparency (CT)
is a set of mechanisms designed to detect, deter, and facilitate remediation of
certificate mis-issuance." As noted in the previous bullet, "certificate
mis-issuance" is not the same as "attack."
Fair point- The text will be changed to reiterate that deterrence, detection
and remediation of mis-issuance as the goal.
- Section 2, paragraph 3 refers to "forged web site certificates," but doesn't
explain what "forged" means. Section 1 said that: Throughout the remainder of
this document we refer to a semantically mis-issued certificate as "bogus." So,
is a "forged" certificate something different from a "bogus" certificate?
Fair point- The instances of “forged” will be changed to “bogus”.
- The final sentence of Section 1, paragraph 5 says that "This extension also
may be used by a browser to request OCSP responses from a TLS server with which
it is communicating [RFC6066][RFC6961]." The sentence should be referring to
the "status_request" TLS extension, but the only extension mentioned before
this sentence is the Authority Information Access (AIA) extension. So, saying
"This extension" is incorrect.
Good catch- The text in this sentence will be revised to refer to “The data
from this extension …”
- Figure 1 is missing arrows whenever information travels from right to left.
Good point- The right to left arrows will be fixed.
- Section 3.1 says that a CA "may have mis-issued a certificate as a result of
an error." This further suggests that the "threats" that are covered by this
draft are not limited to ones involving "a motivated, capable adversary."
Not all attacks are the result of a threat, and attacks are not the same as
threats. Thus no changes are planned in response this comment.
- Section 3.1 (and Section 9.3) contains a link related to the DigiNotar CA
that no longer works.
Good catch- The link in 3.1 will be removed, leaving only the reference number.
The Section 9.3 URI will be replaced with
https://en.wikipedia.org/wiki/DigiNotar
- The organization of Section 3.1 and 3.2 is confusing. Sometimes
self-monitoring subjects and benign third-party monitors are covered together
(in the same section), sometimes they are covered in separate sections even
though there are no differences between the two, and sometimes the third-party
monitor is overlooked. Sometimes the case of a benign third-party monitor is
covered, but the case of a misbehaving third-party monitor is overlooked.
Separate subsections were created when there are meaningful differences in
cases involving self-monitoring vs. third party m monitors, etc. But, when
these distinctions do not matter, the subsections have been merged, and the
text explains this. No changes are planned in response to this comment.
- Section 3.2.1.2, which is supposed to covered the case in which the
certificate is logged but the log is misbehaving, says that "These logs may or
may not issue SCTs, but will hide the log entries from some or all Monitors."
If a certificate is logged (which is part of the premise), doesn't that mean
that an SCT must have been issued? So, why does the text say that "these logs
may or may not issue SCTs"?
Fair point- the text will be changed to remove the reference to not issuing an
SCT.
- Section 3.2.2.1, and other places in the document that make similar
statements, should be updated given that at least one browser is now requiring
SCTs for all newly issued certificates.
One browser does not the Internet make. Moreover, the text in 6962-bis is
rather “flexible” with regard to what a browser MUST do, e.g., “It is up to a
client's local policy to specify the quantity and form of evidence (SCTs,
inclusion proofs or a combination) needed to achieve compliance and how to
handle non-compliance.” Thus no changes are planned in response to this
comment.
- As noted previously, if Section 3.3 is to remain, then the text needs to be
modified to make it clear that Section 3.3 is only about CAs/logs that have had
their keys stolen (compromised) rather than all types of compromise (e.g.,
DigiNotar).
Changes to 3.2 and 3.3 (as noted in response to comment #1) address this
comment.
- Section 3.3, paragraph 1: The final sentence begins "Section 3.3
explored...," but the sentence seems to be referring to Section 3.4.
Good catch- The reference will be changed to 3.4
- Section 3.3.3 begins "As noted in 3.4.1", but there is no Section 3.4.1.
Fair point- This reference will be changed to “Section 3.4”.
- Section 3.4, paragraph 3 says "The malicious CA may have obtained
certificates from the two parents by applying to them for the certificates, or
by compromisingthe parent CAs and creating the certificates without the
knowledge of the CAs." This use of "compromising" seems to be more appropriate
than the use of "compromise" in Section 3.3, as it would include all forms of
compromise, not just cases in which the attacker had stolen a copy of the CA's
key.
Changes to text in 3.3 will address this comment.
- Section 3.5 seems unnecessary, as Section 3.2.1.1.1 already explained that a
malicious CA may provide different status information to different entities.
No changes are planned in response to this comment.
- The final paragraph of Section 3.5 is unrelated to the rest of the section
and seems to be related to the content of Section 3.4.
This text was added in response to a comment ion the list (by Rob, I believe)
who wanted this document to note that the cited revocation status distribution
problems might be addressed by mechanisms not specified by 6962-bis. Thus no
changes are planned in response to this comment.
- Section 4.1 should be reorganized. Sections 4.1.1.3 and 4.1.1.4 fall within
4.1.1 (Certificate Logged), but the contents of Sections 4.1.1.3 and 4.1.1.4 do
not depend on whether or not the certificate was logged.
Fair point – a new section (4.1.3) will be created to address circumstances in
which certificate logging is not a factor, and the two sections noted above
will be moved there.
- Section 4.1.1.2 says that "A log or Monitor that is conspiring with the
attacker," but it is not clear what attacker there is in the scenario being
described.
The attacker is one who wants a syntactically mis-issued certificate to not be
detected and revoked.
- Section 4.1.1.4 says "Unfortunately, experience suggests that many browsers
do not perform thorough syntactic checks on certificates, and so it seems
unlikely that browsers will be a reliable way to detect erroneous
certificates." and Section 4.2.1.4 says "As noted above (4.1.1.4), most
browsers fail to perform thorough syntax checks on certificates." These
sentences should be removed or modified. There is no reason that a browser
should perform thorough syntactic checks on certificates, and there are good
reasons for browsers not to. So, this document should not be labeling this as
unfortunate or a failure. We do not want to encourage browsers to perform
thorough syntax checks on certificates, as this could lead to the same types of
problems that TLS has experienced, where making a change in something causes
deployed products to break.
It seems likely that the primary reason that browsers fail to perform thorough
syntactic checks on certificates is because, at least historically, some CAs
fail to issue syntactically valid certificates. This failure by browsers flies
in the face of PKIX standards; you, as one who usually insists that failures to
follow standards ought to be a capital crime, have no basis for criticizing
this text. No changes will be made in response to this comment.
- The first paragraph of Section 4.2.1.1 includes references to two personal
drafts that have long since expired.
Fair point- The offending references will be removed.
- Section 4.2.1.3 should not fall within Section 4.2.1, since the contents do
not depend on whether or not the certificate was logged.
Fair point- The text from 4.2.1.3 will be moved to 4.2, and 4.2.1.4 will be
relabeled 4.2.1.3.
- Section 4.2.2 says "Since certificates are not logged in this scenario, a
Monitor (third-party or self) cannot detect the issuance of an erroneous
certificate." This is untrue. Section 4 is about certificates that are
erroneous, but not bogus. This means that the Subject identified in the
certificate has a copy of the certificate. So, the Subject can check the
certificate for syntactic errors regardless of whether the certificate is
logged. Similarly, as noted in Section 5.6, the Subject will provide a copy of
the certificate to any third-party Monitor, so any third-party Monitor would
also be able to check the certificate for syntactic errors.
Fair point- This section will be reworded to note that a third-party Monitor,
upon receipt of a certificate from a Subject, could check it for syntactic
consistency, IF it is informed of the type of certificate being Monitored. The
text already notes that a Subject MAY detect syntax errors by examining the
certificate issued to it.
- Section 4.2.2 says "However, even if errors are detected and reported to the
CA, a malicious/conspiring CA may do nothing to fix the problem or may delay
action." As noted previously, no explanation is provided as to why this is a
threat or attack. If the Subject knows that there are errors in the
certificate, then the Subject can just get another certificate (from a
different CA, if necessary). It doesn't matter whether the CA revokes the
erroneous certificate or not.
See previous comment on why syntactic mis-issuance is included in this document.
- Section 5.3 says
o It also will likely require the targeted Subject to provide assurances that
it is the authorized entity representing the Subject name (subjectAltname) in
question. Thus a Subject should not expect immediate revocation of a contested
certificate. The time frame in which a CA will respond to a revocation request
usually is described in the CPS for the CA. Other certificate fields and
extensions may be of interest for forensic purposes, but are not required to
effect revocation nor to verify that the certificate to be revoked is bogus or
erroneous, based on applicable criteria.
This text seems to say that only the "Subject name (subjectAltname)" is
required "verify that the certificate to be revoked is ... erroneous." This
cannot be correct, as a syntactic check a certificate would be looking for
errors in many fields and extensions other than "Subject name (subjectAltname)."
Fair point- The sentence will, be truncated after “to effect revocation”.
- Section 5.4 (and similar text elsewhere in the document) seems out of date
given that at least one browser now rejects any newly issued certificates that
are not accompanied by an SCT.
See prior comment on why one browser’s behavior is not viewed as sufficient to
merit a change to this and similar text.
- Section 5.6, paragraph 4 says that "A Monitor must not rely on certificate
discovery mechanisms to build the list of valid certificates since such
mechanisms might result in bogus or erroneous certificates being added to the
list." What would be the risk if an erroneous certificate was added to the
list? When a Monitor is obtaining a list of certificates for the Subject to be
monitored, wouldn't we want erroneous certificates to be included in that list
so that the Monitor has a chance to detect the error?
The text about not relying on certificate discovery mechanisms was added
explicitly at the behest of Santosh. If he does not choose to explain his
reasoning the sentence will be removed.
- Section 5.6, paragraph 5 says "If a Monitor is compromised by, or conspires
with, an attacker, it will fail to alert a Subject to a bogus or erroneous
certificate targeting that Subject, as noted above." As noted previously, this
document needs to explain how an attacker can "target" a Subject with an
erroneous certificate.
As noted above, Ben insisted that syntactically erroneous certificates were
considered mis-issued, and hence motivated inclusion of the text in Section 4.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
