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

Stephen Kent <s@zerho.info> Wed, 09 May 2018 12:49 UTC

Return-Path: <s@zerho.info>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A06124205 for <trans@ietfa.amsl.com>; Wed, 9 May 2018 05:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zerho.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzSjzGAXGxC3 for <trans@ietfa.amsl.com>; Wed, 9 May 2018 05:49:11 -0700 (PDT)
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA491241FC for <trans@ietf.org>; Wed, 9 May 2018 05:49:10 -0700 (PDT)
Date: Wed, 09 May 2018 08:49:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zerho.info; s=protonmail; t=1525870143; bh=qrCR0CzM3x83C5ddZj5OJtvkvVLHzChq9zIa8ceXwNM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=H6e2lBqYvmDIinkquXM0Yawx40x1Kll/JqKFp0ILvmRgN/29qBv70YzyWCvjweap2 OMqt1MYIV0rqf4pKKbRsC/G0nMQv1bnPDfHQMu794KPZcRAy86Rq1H2VFND6XprXGK cpCqenbKbs1JU9plBEMHkKD2C4tlUlR+9h3zEiSc=
To: "David A. Cooper" <david.cooper@nist.gov>
From: Stephen Kent <s@zerho.info>
Cc: Paul Wouters <paul@nohats.ca>, Melinda Shore <melinda.shore@gmail.com>, Trans <trans@ietf.org>
Reply-To: Stephen Kent <s@zerho.info>
Message-ID: <IUUXIbDImicbov7jLKxe4l9QVrF_cCO0F1_mY4LpATYvr-Eag7fAJwnwqnviKXU3drx1vKgpuE6hkehmUMBq2QzPSKNKaMdM3D6LIMv2Gig=@zerho.info>
In-Reply-To: <cf3fd01c-a1f2-0cd0-d1a2-cda7b9558986@nist.gov>
References: <alpine.LRH.2.21.1804161658150.17034@bofh.nohats.ca> <cf3fd01c-a1f2-0cd0-d1a2-cda7b9558986@nist.gov>
Feedback-ID: J6dPlme6glBGJLMEtGsaqJPE6vPDBSW6lOheJXLXjEWBxgn8P1CEZKbZGc4D01YOct3XeTXymnV_hlw9t4YeHg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_e95939da964a0fe229910303e029e0ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/nnndU3ySIVs6po3wsX7jjRo89LI>
Subject: Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 12:49:15 -0000

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.