Re: [Trans] The trans threat analysis document

[David A. Cooper]

On 08/03/2018 09:40 PM, Paul Wouters wrote: The issues that seem to need consensus can be seen in thie message: https://www.ietf.org/mail-archive/web/trans/current/msg03163.html David, can you tell us which issues you raised in your message that you believe are not yet resolved with the -14 version that was released in response to your message? Paul, Below are the comments that I raised in my message on May 9 that I believe have not been resolved. However, it does not seem accurate to suggest that the only issues that need consensus are the ones from my message on May 9. Andrew Ayer and Ryan Sleevi also raised issues with the most recent draft (see for example https://www.ietf.org/mail-archive/web/trans/current/msg03178.html) and I have not seen any messages on the list since then to suggest that the issues they raised have been address - only a comment from Steve Kent suggesting that he does not feel any changes are needed (https://www.ietf.org/mail-archive/web/trans/current/msg03225.html). In addition, Eric Rescorla submitted some, mainly editorial, comments on draft -12 (https://www.ietf.org/mail-archive/web/trans/current/msg03103.html), and there was never any response to his comments, many of which remain unaddressed. I would also like to note again, given the nature of https://www.ietf.org/mail-archive/web/trans/current/msg03225.html, that I submitted the comments on May 9 specifically because of a request from the WG chairs (https://www.ietf.org/mail-archive/web/trans/current/msg03146.html) to "please review the entire document." So, any implication that there was something inappropriate about submitting comments on new issues after draft -13 was published is rather unfortunate. On 05/09/2018 08:49 AM, Stephen Kent wrote: 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? 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. 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. 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]." 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. 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.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. 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. 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. 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." 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)? 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. 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. 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." 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. 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.

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans