Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis

["David A. Cooper" <[e-mail]>]

On 04/16/2018 05:01 PM, Paul Wouters wrote:

Hi,

This starts a 3 week WGLC for draft-ietf-trans-threat-analysis

Previously, there were some contentious issues regarding the dual CA
attack that dkg came up with. The current version should address all
those issues. But since it has been a (very!) long time since this
document was discussed and consumed, please review the entire document.

https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13" rel="nofollow">https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13

Paul & Melinda

Hello Paul, Melinda,

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:

1. 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" rel="nofollow">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.
   

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.

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."

4. The 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."

5. 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?
   

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.

7. Figure 1 is missing arrows whenever information travels from right to left.

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."

9. Section 3.1 (and Section 9.3) contains a link related to the DigiNotar CA that no longer works.

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.

11. 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"?

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.

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).
    

14. Section 3.3, paragraph 1: The final sentence begins "Section 3.3 explored...," but the sentence seems to be referring to Section 3.4.

15. Section 3.3.3 begins "As noted in 3.4.1", but there is no Section 3.4.1.

16. 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 compromising the 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.

17. 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.

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.

19. 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.

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.

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.
    

22. The first paragraph of Section 4.2.1.1 includes references to two personal drafts that have long since expired.

23. 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.

24. 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.

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.

26. Section 5.3 says

• 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)."

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.

28. 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?

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.