On 05/09/2018 08:49 AM, Stephen Kent wrote:
2. 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.
The response is not related to the comment. The comment did not suggest that
issuing a certificate with syntactic
errors shouldn't be considered mis-issuance, nor did it suggest that the threat
analysis document shouldn't discuss
syntactic mis-issuance. The problem is that the text suggests that the issuance
of a certificate with syntactic
errors might be part of an attack, but it does not explain how it could be part
of an attack.
This text is particularly confusing in the case in which the Subject is aware
that there is an error in the
certificate. The text states that "a malicious CA may do nothing or may delay
the action(s) needed to remedy the
problem." How can the CA "attack" the Subject in this way when the Subject can
just get a new certificate from a
different CA and not use the mis-issued certificate?
The source of the problem may be that the document appears to be using rather bizarre
definitions for "threat" and
"attack." For example, there is new text in Section 2 that says:
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).
The parenthetical makes no sense. It seems to be based on some definition of
"attack" that encompasses unintentional
errors while also relying on an incorrect definition of "threat" (see below).
For what reasonable definition of
"attack" could one say that an attack may be the result of errors in the
context of certificate mis-issuance?
3. 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).”
I can find no such DoD definition for threat, cannot find the word "threat" in
the Cornell CS 5430 syllabus, and
cannot seem to access either the MIT course 6.805 syllabus or the NRC report. I
do see, however, that Steve Kent is
listed as one of the authors of the NRC report, which suggests that it is not a
independent source for the
definition. Certainly in some cases the only source of a threat may be a "motivated,
capable adversary," and in such
a context the term may be described in that way, but that does not mean the
definition of threat is limited to
motivated, capable adversaries.
On the other hand, there are sources such as
https://dictionary.cambridge.org/us/dictionary/english/threat and
https://en.wikipedia.org/wiki/Threat_(computer). The Wikipedia article specifically
notes that "a threat type can
have multiple origins" and it lists deliberate, accidental, environmental, and
negligence.
Also, note that in the original comment I did not suggest that mis-issuance is a
threat. When I said "Mis-issuance
may be the result of carelessness, but it is still a threat" I intended to
suggest possibility that someone could act
carelessly is a threat.
4. 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.
This text is still odd, and seems inconsistent with the previous paragraph. The
previous paragraph has new text that
says "some attacks may be the result of errors," whereas this paragraph now
says:
As noted above, the goals of CT are to deter, detect, and facilitate
remediation of attacks that result
in certificate mis-issuance in the Web PKI. (CT also may facilitate
detection and remediation of errors
that result in certificate mis-issuance.)
So, unlike in the previous paragraph, this text seems to acknowledge that an
error is not an attack. It is still not
clear the reason for two separate sentences. What is actually "noted above" is that
CT is "designed to detect, deter,
and facilitate remediation of certificate mis-issuance" (regardless of the
reason the mis-issuance happened), so why
imply that it is primarily about mis-issuance that was caused by an attack,
especially when Section 4 is devoted to
syntactic mis-issuance, which is far more likely to be the result of an error
than an attack.
6. 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 …”
This text is still incorrect. It now says "The data from this [Authority
Information Access] extension also may be
used by a browser to request OCSP responses from a TLS server with which it is
communicating [RFC6066][RFC6961]."
To obtain OCSP responses from a TLS server the browser just sends a
status_request [RFC6066] (or status_request_v2
[RFC6961]) extension in the ClientHello. The status_request extension sent in
the ClientHello does not contain any
information from the server certificate's AIA extension - the client doesn't
obtain the server's certificate until
after sending the ClientHello. Also, there is no information in the AIA
extension that could be included in the
status_request extension.
The sentence should just be changed to something like: "A browser may also
request OCSP responses from a TLS server
with which it is communicating [RFC6066][RFC6961]."
8. 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.
The response here seems to be based on the highly unusual, but unspecified definition of
"attack" used in this
document. The response certainly has nothing to do with the comment, which
doesn't suggest anything like what the
response implies that it does.
10. 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.
12. 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.
See https://www.ietf.org/mail-archive/web/trans/current/msg03160.html and
https://www.ietf.org/mail-archive/web/trans/current/msg03103.html.
There was no suggestion that one browser makes the Internet. The problem is
that the text says, for example:
If a browser rejects certificates without SCTs (see Section 5.4), CAs may be
"encouraged" to log the
certificates they issue. This, in turn, would make it easier for
Monitors to detect bogus certificates.
However, the CT architecture does not describe how such behavior by
browsers can be deployed
incrementally throughout the Internet. As a result, this attack model
does not assume that browsers will
reject a certificate that is not accompanied by an SCT.
It might be perfectly fine to say that the attack model does not assume that
browsers will reject a certificate that
is not accompanied by an SCT since the CT architecture does not require
browsers to do so. But, that is not what the
text says. The text says that the model doesn't make the assumption because the
CT architecture does describe how
browsers can do it.
The comment was not suggesting that since Chrome requires SCTs for all newly
issued certificates, the attack model
needs to assume that browsers will reject certificates not accompanied by an
SCT. The point is that since the
developers of Chrome have described "how such behavior by browsers can be
deployed incrementally throughout the
Internet," the lack of such a description in "the CT architecture" isn't
relevant. Browser developers may have good
reasons not to reject certificates that are not accompanied by an SCT, but it
is not because no one described to them
how to deploy such behavior.
13. 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.
This problem is still not addressed. The DigiNotar case was moved to Section
3.3, where parts of the corresponding
paragraph notes that not all compromises involve theft of the private key.
However, the second paragraph of Section
3.3 still says:
The section focuses on undetected compromise of CAs. Such compromises
warrant some additional
discussion, since some relying parties may see signed objects issued by
the legitimate (non-malicious)
CA, others may see signed objects from its compromised counterpart, and
some may see objects from both
and Section 3.3.1 begins:
In the case of a compromised (non-malicious) CA, an attacker uses the
purloined private key to generate a
bogus certificate (that the CA would not knowingly issue).
So while there is now some text that notes that not all compromises involve
theft of the private key, there is still
other text that says otherwise.
15. 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”.
This reference was corrected, but draft -14 still has problems with incorrect
references. I have not checked all of
the references, but there is a parenthetical in Section 3.3.1 that says "(see
3.1.2.2)" even though there is no
Section 3.1.2.2. Similarly, Section 4.2.1.3 begins "As noted above (4.1.1.4),"
but there is no Section 4.1.1.4.
18. 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.
Both this comment and
https://www.ietf.org/mail-archive/web/trans/current/msg03160.html noted that
the final
paragraph of Section 3.5 is related to the attack in Section 3.4 and not to the
contents of Section 3.5. The text has
nothing to do with the rest of Section 3.5 nor does it "note that the cited
revocation status distribution problems
might be addressed by mechanisms not specified by 6962-bis."
20. 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.
This is a non-answer. Did the attacker do something that caused the certificate
to be mis-issued? If so, how? The CA
can't be the attacker since it is non-malicious in Section 4.1. Is this
sentence considering the possibility that the
Subject could an an "attacker," sending a certificate request that somehow
tricks the CA into issuing an erroneous
certificate? Is there any other than the CA or Subject that could influence the
contents of the certificate?
Could it be that the "attacker" had no influence over the issuance of the
certificate, but was just hoping that a
certificate would be mis-issued? If so, what role does it play in the "attack"
(other than passive observer)?
21. 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.
As I noted previously (see, for example,
https://www.ietf.org/mail-archive/web/trans/current/msg03162.html) this
response is not related to the comment. There is a difference between a browser
checking for things that can be
expected not to change (e.g., is the keyUsage extension DER encoded -
https://www.ietf.org/mail-archive/web/trans/current/msg03172.html) and checking
for things may may change (e.g., does
a subject field that doesn't contain an organizationName attribute contain a
streetAddress attribute -
https://www.ietf.org/mail-archive/web/trans/current/msg03162.html).
While the underlying syntax rules for X.509 certificates can be presumed to be
unchanging, certificate profiles can
change over time, and this document makes clear that syntax checks includes
checking for conformance with the
appropriate profile. If a browser performed "thorough syntax checks" as this
document defined that term, then it
would be effectively checking for conformance to a particular version of a
certificate profile. There can't be an
assumption that every browser on every client will be updated as soon as any
certificate profile changes, so browsers
performing such checks would create problems. As a related example, consider
the recent discussions in the TLS WG
about ossification, the need to make last-minute changes to the TLS 1.3
protocol in order to deal with
version-intolerant servers and middleboxes, and the addition of text to RFC
8446 about protocol invariants.
There seems to be some confusion about the nature of syntactic mis-issuance.
Section 1 of the threats document says:
A certificate is characterized as syntactically mis-issued (aka
erroneous) if it violates syntax
constraints associated with the class of certificate that it purports to
represent. Syntax constraints
for certificates are established by certificate profiles, and typically
are application-specific. For
example, certificates used in the Web PKI environment might be
characterized as domain validation (DV) or
extended validation (EV) certificates. Certificates used with
applications such as IPsec or S/MIME have
different syntactic constraints from those in the Web PKI context.
Yet, in the response to the above comment and in
https://www.ietf.org/mail-archive/web/trans/current/msg03174.html,
Steve seems to suggest that checking for syntactic mis-issuance is really about
checking whether certificates are
valid with respect to RFC 5280. Of course one could check for both types of
errors. However, there is a very big
difference between just checking for compliance with X.509 (RFC 5280) and
checking for compliance with the current
profile rules for DV certificates.
25. 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.
This is not a response. Neither this comment nor any other comment suggested
that syntactic mis-issuance should not
be included in the document.
26. 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”.
The sentence was supposed to end just "to effect revocation," but it just ends to
"to effect."
27. 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.
See response to prior comment. A method has been defined that is compatible
with incremental deployment. It may not
have been defined in an RFC, but it has been defined. So, the text shouldn't be
implying that no one has defined a
mechanism that accommodates incremental deployment of a capability to reject
certificates that have not been logged.
29. 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.
Again, the comment does not suggest that syntactically erroneous certificates
are not mis-issued nor does it suggest
that syntactic mis-issuance should not be discussed in this document. So, the
response does not address the comment.
