Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
Folks, Ben Kudak politely noted that my reply to Andrew's comments lost all formatting when I sent it. I have attached the formatted version that I prepared, as a PDF, to facilitate review. Sorry, Steve ‐‐‐ Original Message ‐‐‐ On May 7, 2018 2:29 PM, Andrew Ayer wrote: > > > draft-ietf-trans-threat-analysis-13 has a number of issues that ought > > to be fixed before it's published. > > A. Logs do not check for syntactic misissuance > > Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check, > > or ought to check, submitted certificates for syntactic misissuance. > > Page 20 says that syntactic misissuance will be detected "only if" a > > (pre-)certificate is submitted to a log that performs syntactic checks. > > This is not an intended function of logs, and not a single one of the > > 58 logs currently in operation performs syntactic misissuance checks. > > Furthermore, having logs perform this function would violate separation > > of concerns. Instead, monitors perform syntactic misissuance checks. > > crt.sh, for instance, runs all certificates through several certificate > > linters. > > Page 20 says that "syntactic checking [of pre-certificates] by a log > > helps avoid issuance of an erroneous certificate." This is contrary to > > RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate > > is a binding commitment by the CA to issue a certificate. It would > > be dangerous for a CA to follow the advice on page 20, as browsers > > rightly consider misissuance of a pre-certificate to be equivalent to > > misissuance of a real certificate. CAs must perform syntactic checks on > > the TBSCertificate prior to signing anything. > > Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans > > and have expired. > > I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely. > > B. Conflation of log misbehavior and CA misbehavior > > Page 4 says that if a bogus SCT is discovered, it would trigger > > a revocation request. Page 26 says that browsers need to "reject > > certificates that contain SCTs from conspiring logs." > > Page 3 says "if an RP verified that a certificate that claims to have > > been logged has a valid log entry, the RP would have a higher degree of > > confidence that the certificate is genuine." > > But behavior of a log says nothing about whether a certificate was > > properly issued. A properly-issued certificate might be logged to a > > a misbehaving log, and a misissued certificate might be logged to a > > well-behaved log. > > Therefore, browsers should not consider a certificate more likely to > > be genuine just because it's logged, and if a certificate contains an > > embedded SCT from a log that's known to be bad, the browser should reject > > only that SCT, and still check SCTs from other logs. And there is no need > > to revoke a properly-issued certificate just because it's submitted to > > a log that misbehaves. > > Section 5.3 says that "evidence of a bogus or erroneous certificate" > > can be "in the form of a log entry and/or SCT." An SCT is irrelevant > > for this, as it attests only to log behavior. > > C. Response to log misbehavior > > On pages 4, 9, and 13, the draft says that monitors should not "trust" > > or "rely upon" misbehaving logs. But monitors don't trust or distrust > > logs - they just view logs as a source of certificates. Browsers, on > > the other hand, do trust and distrust logs. For example, after two logs > > (WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but > > Cert Spotter and crt.sh continued monitoring them until they shut down. > > The document should be updated to remove mention of monitors trusting or > > relying upon logs, and to make clear that the primary response to a > > misbehaving log is for browsers to distrust it. > > D. Signature/chain mutation attack > > There's another way a log can misbehave which ought to be mentioned in > > section 3.1.1.2. A misbehaving log that conspires with a CA could log > > a misissued certificate, but mutate the certificate's signature or chain > > such that the certificate is no longer cryptographically attributable to > > the CA. The CA could then plausibly deny that it issued the certificate. > > Since the signature and chain are not part of the Merkle Tree, the SCT > > will be accepted by browsers and be auditable, despite the log entry > > being mutated and useless for responding to the misissuance. > > Monitors should be sure to validate the signature and chain of logged > > certificates so that this misbehavior can be detected. > > E. Chrome is requiring SCTs now > > As David A. Cooper pointed out, Chrome is now requiring new certificates > > to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates. > > F. Organization > > The organization of the draft seems sub-optimal. At a high level, the > > document is broken up into sem
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
On Tue, May 15, 2018 at 10:50 AM, David A. Cooper wrote: > I can't speak for Steve, but I can provide an example of a syntax error I > encountered as a result of "quirks of CA certificate-issuing software." > > Many years ago when I was tasked to check whether certificates being > issued by a CA were being issued in conformance with the appropriate > profile, I discovered that the keyUsage extensions in the certificates were > not DER encoded. The contents of the extension were correct according to > BER, but not DER, and everything else about the certificate was correct. > > This must have been the fault of the developer of the CA software and not > the company operating the CA. This would not be a security or trust failure > by the CA and most clients wouldn't even notice the problem. There would, > however, be the risk that some client software somewhere would not accept > the certificate simply because of the encoding problem, so it was useful > for the encoding problem to be identified and fixed. > I think we may disagree on this assessment. I agree that it presents an interoperability issue - but I think a failure of the CA to actually ensure that their software conforms to the profile is a grounds for concern. We've seen a spectrum of CAs and competencies - and I know of some CAs that have expressly written tools to ensure everything they issue conforms to the appropriate profile (i.e. they actually understand their systems) versus CAs that think that if you use some COTS product, you've got Production Grade issuance. CT very much cares about detecting these issues, in practice, and in fact, it's the detection, discovery, and mitigation of precisely these sorts of issues that have demonstrated the most immediate practical value. Further, because of the existence of such linting tools, CAs are now expected to run such linting tools prior to their issuance. It is thus, to that end, that having logs reject such certificates (i.e. logs as linters) that would undermine the development of and enforcement of issuance policy. Linting-as-a-service is provided by separable endpoints, and while such services can mask the underlying issues that CAs have, that's conversely part of the goal of having such APIs - to check a tbsCertificate before the CA has actually signed the material, while checking a precertificate/certificate means that the CA has actually signed it, and is notable for detection and censure. ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
I can't speak for Steve, but I can provide an example of a syntax error I encountered as a result of "quirks of CA certificate-issuing software." Many years ago when I was tasked to check whether certificates being issued by a CA were being issued in conformance with the appropriate profile, I discovered that the keyUsage extensions in the certificates were not DER encoded. The contents of the extension were correct according to BER, but not DER, and everything else about the certificate was correct. This must have been the fault of the developer of the CA software and not the company operating the CA. This would not be a security or trust failure by the CA and most clients wouldn't even notice the problem. There would, however, be the risk that some client software somewhere would not accept the certificate simply because of the encoding problem, so it was useful for the encoding problem to be identified and fixed. It's not clear, however, that this is the type of error draft-ietf-trans-threat-analysis has in mind. Section 1 of the 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. Similarly, https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks makes no mention of encoding errors, such as the one I encountered. But, my guess would be that syntactic mis-issuance was intended to include encoding errors in addition to violations of application-specific certificate profiles. NOTE: I have no position of which entity, if any, should be checking for these types of errors, or on how the discovery of such errors should be handled if they are found. On 05/14/2018 10:06 PM, Ryan Sleevi wrote: Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate. I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g.., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again. I don't think that would be a positive change, and have to agree with Andrew here, that it would seem moreso detrimental to the ecosystem that CT aims to improve. I'm not sure the rationale for ditching the certificate is at all reasonable - the fact that such a certificate was even considered as 'log worthy' by a CA is a demonstration of a failure by that CA to uphold public trust. In that model, it's vitally essential for the Log to make that known - not to help the CA cover it up. In this regard, that the CA has used its key to sign something - anything - that fails the checks is a demonstration of risk to any PKI that trust this CAs. I think painting it as quirks does a disservice - it's an operational failure of the CA, and thus, by proxy, a security and trust failure by the CA. That is, if anything, one of the most noteworthy events - rather than the inverse. CAs must perform syntactic checks on the TBSCertificate prior to signing anything. In principle yes, but in practice, … “quirks of CA
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
On Mon, May 14, 2018 at 11:26 AM, Stephen Kent wrote: > Also, note that 6962-bis says: “Logs SHOULD accept certificates and > precertificates that are fully valid according to RFC 5280 [RFC5280] > verification rules and are submitted with such a chain.” This text suggests > that some logs might choose to verify certificate syntax as part of path > validation, although none need to do so. The text goes on to note that a > log may choose to accept certs that violate some 5280 rules, which also > suggests to me that syntax checking is not outlawed by 6269-bis. It > acknowledges that this leniency is needed to accept “quirks of CA > certificate-issuing software.” > Perhaps I'm misunderstanding, but that sounds like an inversion of one of the goals of CT. That is, that logs should do as little verification as possible, and what verification they do perform is not a function of an ecosystem benefit or of CA benefit, but rather, of mitigation of spam or risk to the log itself. > This is not an intended function of logs, and not a single one of the 58 > logs currently in operation performs syntactic misissuance checks. > Furthermore, having logs perform this function would violate separation of > concerns. Instead, monitors perform syntactic misissuance checks. crt.sh, > for instance, runs all certificates through several certificate linters. > > The document examines possible ways that one might detect syntax problems > and how elements of CT might facilitate remediation of detected problems. > Logs, if they chose to perform such checks, could help in this respect and > that’s why they are discussed, irrespective of how logs currently operate. > Also, I don’t see where 6962-bis states that a monitor performs syntax > checks. For example, the 6962-bis text for the description of Monitor > operation still says “Monitors watch logs to check that they behave > correctly, for certificates of interest, or both.” (The “or both” makes no > sense here, as I noted several times in 2017, but …) > I have to agree with Andrew here, to the extent that we have considered for Chrome formulating explicit policies prohibiting logs from doing what's described here. Logs that perform such checks would not help the ecosystem, but rather, they would actively harm the PKIs they were serving, by preventing public record of and discovery of misissuance. I'm also not sure why you believe "or both" is not reflective of the reality. There are monitors that simply treat Logs as databases of certificates, without regard for ensuring the cryptographic properties - on a reliance of other members of the ecosystem performing such verification, and perhaps agreeing upon some common shared STH. In this model, "or both" is entirely reflective of real world. > Page 20 says that "syntactic checking [of pre-certificates] by a log helps > avoid issuance of an erroneous certificate." This is contrary to RFC6962 > and RFC6962-bis, which both state that issuing a pre-certificate is a > binding commitment by the CA to issue a certificate. It would be dangerous > for a CA to follow the advice on page 20, as browsers rightly consider > misissuance of a pre-certificate to be equivalent to misissuance of a real > certificate. > > I'll change the text on page 20 to state that a log could help a CA detect > and avoid issuing a syntactically erroneous cert. Also, what 6962 says is > not relevant here- that was an experimental doc, not standards track. > Submission of a pre-cert to a log probably does indicate an internet to > issue a cert, but certificate issuance need not result in delivery to a > Subject. If a CA were advised by a log that a certificate was malformed > (e.g., due to “quirks of CA certificate-issuing software” then the CA could > ditch the certificate, or revoke it, and try again. > I don't think that would be a positive change, and have to agree with Andrew here, that it would seem moreso detrimental to the ecosystem that CT aims to improve. I'm not sure the rationale for ditching the certificate is at all reasonable - the fact that such a certificate was even considered as 'log worthy' by a CA is a demonstration of a failure by that CA to uphold public trust. In that model, it's vitally essential for the Log to make that known - not to help the CA cover it up. In this regard, that the CA has used its key to sign something - anything - that fails the checks is a demonstration of risk to any PKI that trust this CAs. I think painting it as quirks does a disservice - it's an operational failure of the CA, and thus, by proxy, a security and trust failure by the CA. That is, if anything, one of the most noteworthy events - rather than the inverse. > CAs must perform syntactic checks on the TBSCertificate prior to signing > anything. > > In principle yes, but in practice, … “quirks of CA certificate-issuing > software” > I'm not sure what you're referring to as quirks again. This is a rather fatal failure mode, and one of the express go
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
Andrew, Thanks for taking the time to review the document and for the nice organization of your comments. A. Logs do not check for syntactic misissuance Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check, or ought to check, submitted certificates for syntactic misissuance. Page 20 says that syntactic misissuance will be detected "only if" a (pre-)certificate is submitted to a log that performs syntactic checks. There was no intent to suggest that logs do or ought to perform syntax checks. Sorry for any confusion in that regard. I did find several places where uppercase reserved words appear, which is inappropriate for an informational RFC. I will change all of these to lowercase. Also, note that 6962-bis says: “Logs SHOULD accept certificates and precertificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain.” This text suggests that some logs might choose to verify certificate syntax as part of path validation, although none need to do so. The text goes on to note that a log may choose to accept certs that violate some 5280 rules, which also suggests to me that syntax checking is not outlawed by 6269-bis. It acknowledges that this leniency is needed to accept “quirks of CA certificate-issuing software.” This is not an intended function of logs, and not a single one of the 58 logs currently in operation performs syntactic misissuance checks. Furthermore, having logs perform this function would violate separation of concerns. Instead, monitors perform syntactic misissuance checks. crt.sh, for instance, runs all certificates through several certificate linters. The document examines possible ways that one might detect syntax problems and how elements of CT might facilitate remediation of detected problems. Logs, if they chose to perform such checks, could help in this respect and that’s why they are discussed, irrespective of how logs currently operate. Also, I don’t see where 6962-bis states that a monitor performs syntax checks. For example, the 6962-bis text for the description of Monitor operation still says “Monitors watch logs to check that they behave correctly, for certificates of interest, or both.” (The “or both” makes no sense here, as I noted several times in 2017, but …) Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate. I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again. CAs must perform syntactic checks on the TBSCertificate prior to signing anything. In principle yes, but in practice, … “quirks of CA certificate-issuing software” Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans and have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely. I believe that the two I-Ds in question were generated because of the text that I was writing here, not the other way around. The text in 4.1.1.1 says that a log could optionally check for syntax problems; it does not say that they MUST/SHOULD do so. I'll change the text in 4.1.1.1 to note, parenthetically, that syntax checks by a log are optional. B. Conflation of log misbehavior and CA misbehavior Page 4 says that if a bogus SCT is discovered, it would trigger a revocation request. Page 26 says that browsers need to "reject certificates that contain SCTs from conspiring logs." Page 4 says that discovery of a bogus SCT would "presumably, trigger" a revocation request. Page 26 does not require a browser to reject a certificate that does not contain an SCT. (As noted above, this document is not intended to establish requirements for any element of the CT system.) 5.4 describes issues that might arise IF such behavior were adopted. Page 3 says "if an RP verified that a certificate that claims to have been logged has a valid log entry, the RP would have a higher degree of confidence that the certificate is genuine." But behavior of a log says nothing about whether a certificate was properly issued. A properly-issued certificate might be logged to a a misbeha
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
I have been unable to find anywhere in my comments where I suggested that syntactic mis-issuance should not be discussed in the document. The "responses" you provided have nothing to do with my comments. On 05/09/2018 08:49 AM, Stephen Kent wrote: 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.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 Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
On 05/09/2018 08:49 AM, Stephen Kent
wrote:
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.
If only I had a nickel for every time you made some false accusation
about me, I'd be retired by now.
Please see the message below, which I sent to mail list before you
sent your response above.
Even in your response yesterday you said that "a certificate that
violated the syntax imposed by a criteria such as the CABF would
qualify as mis-issued," so the document does not intend to suggest
that syntactic checks are just about PKIX standards, they are also
about certificate profiles, which are subject to change.
This isn't about accommodating CAs that issue certificates
incorrectly, but about acknowledging that (1) certificate profiles
can change over time and (2) some clients will continue to use
browsers that are very old.
Forwarded Message
Subject:
Re: [Trans] WGLC started for
draft-ietf-trans-threat-analysis
Date:
Mon, 7 May 2018 16:48:44 -0400
From:
David A. Cooper
To:
Andrew Ayer
CC:
Paul Wouters , Trans
, Melinda Shore
I think it's fine for browsers to check for syntactic errors in
certificates. However, I interpreted "thorough syntactic checks on
certificates" to mean that browsers should be performing checks
such as the ones described in
https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks
and
https://tools.ietf.org/html/draft-kent-trans-extended-validation-cert-checks.
Most of the checks in these drafts are fine, as they are checks
for requirements that are unlikely to change. However, some of the
checks are more problematic. For example, the first of these
drafts say that for DV certificates
if the [subject] name does not contain an
organizationName attribute,
then the streetAddress attribute MUST NOT be present.
If
the organizationName attribute is present, the
streetAddress
attribute MAY be present. This requirement is
derived from
section 9.2.4b of [CABF-DV].
What if a browser implemented a check for this and then the
CA/Browser Forum later updated their Baseline Requirements to
allow a streetAddress attribute in the subject fields of
certificates that do not contain an organizationName attribute?
This wouldn't cause a problem for users who keep their browsers up
to date, but some clients continue to use browsers that are very
old.
___
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
On Wed, 9 May 2018, Stephen Kent wrote: 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. No. Any WGLC is about the entire document, and everyone is free and encouraged to comment about the entire document. The IETF has no process of last calling a part of a draft. I encourage everyone to read the entire document and comment. Especially, since the document has been dormant for so long. Paul ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
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 motivate
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
I think it's fine for browsers to check for syntactic errors in certificates. However, I interpreted "thorough syntactic checks on certificates" to mean that browsers should be performing checks such as the ones described in https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks and https://tools.ietf.org/html/draft-kent-trans-extended-validation-cert-checks. Most of the checks in these drafts are fine, as they are checks for requirements that are unlikely to change. However, some of the checks are more problematic. For example, the first of these drafts say that for DV certificates if the [subject] name does not contain an organizationName attribute, then the streetAddress attribute MUST NOT be present. If the organizationName attribute is present, the streetAddress attribute MAY be present. This requirement is derived from section 9.2.4b of [CABF-DV]. What if a browser implemented a check for this and then the CA/Browser Forum later updated their Baseline Requirements to allow a streetAddress attribute in the subject fields of certificates that do not contain an organizationName attribute? This wouldn't cause a problem for users who keep their browsers up to date, but some clients continue to use browsers that are very old. Section 5.6 says that the Monitor needs to obtain a list of certificates for the Subject to use as a reference, and then it 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." The phrase "or erroneous" should be removed. There is no risk if the Monitor adds an erroneous certificate (that is not bogus) to the list of valid certificates, as it will not not mean "that the monitor would fail to alert the Subject about an erroneous certificate." If a Monitor is going to perform syntactic checks on certificates, then it should check all certificates for syntactic errors, regardless of how they came into its possession, even certificates that are received from the Subject in a secure manner for the purpose of creating a reference list of non-bogus certificates. On 05/07/2018 03:56 PM, Andrew Ayer wrote: On Fri, 4 May 2018 14:51:47 -0400 "David A. Cooper" wrote: 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. The trend in Firefox and Chrome is to make their certificate validators much stricter about "syntactic" errors. I think the main point of section 4.1.1.4 is that it's not feasible for browsers to notify other parties when it detects a syntactically misissued certificate, so these checks need to be performed by monitors. I think this sentence should just be dropped, as it's not true anymore and tries to moralize about a controversial issue. 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? Monitors look for subject names, not specific certificates. The list of valid certificates is so the monitor doesn't raise an alarm when it finds a legitimate certificate for a monitored subject name. So the answer to your first question is that the monitor would fail to alert the Subject about an erroneous certificate. This could be clarified in section 5.6. The answer to your second question is that the monitor would still detect erroneous certificates, because it's monitoring based on subject name. This seems to be clear already from the description of a monitor in the introduction. Regards, Andrew ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
On Fri, 4 May 2018 14:51:47 -0400 "David A. Cooper" wrote: > 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. The trend in Firefox and Chrome is to make their certificate validators much stricter about "syntactic" errors. I think the main point of section 4.1.1.4 is that it's not feasible for browsers to notify other parties when it detects a syntactically misissued certificate, so these checks need to be performed by monitors. I think this sentence should just be dropped, as it's not true anymore and tries to moralize about a controversial issue. > 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? Monitors look for subject names, not specific certificates. The list of valid certificates is so the monitor doesn't raise an alarm when it finds a legitimate certificate for a monitored subject name. So the answer to your first question is that the monitor would fail to alert the Subject about an erroneous certificate. This could be clarified in section 5.6. The answer to your second question is that the monitor would still detect erroneous certificates, because it's monitoring based on subject name. This seems to be clear already from the description of a monitor in the introduction. Regards, Andrew ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
draft-ietf-trans-threat-analysis-13 has a number of issues that ought to be fixed before it's published. A. Logs do not check for syntactic misissuance Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check, or ought to check, submitted certificates for syntactic misissuance. Page 20 says that syntactic misissuance will be detected "only if" a (pre-)certificate is submitted to a log that performs syntactic checks. This is not an intended function of logs, and not a single one of the 58 logs currently in operation performs syntactic misissuance checks. Furthermore, having logs perform this function would violate separation of concerns. Instead, monitors perform syntactic misissuance checks. crt.sh, for instance, runs all certificates through several certificate linters. Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate. CAs must perform syntactic checks on the TBSCertificate prior to signing anything. Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans and have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely. B. Conflation of log misbehavior and CA misbehavior Page 4 says that if a bogus SCT is discovered, it would trigger a revocation request. Page 26 says that browsers need to "reject certificates that contain SCTs from conspiring logs." Page 3 says "if an RP verified that a certificate that claims to have been logged has a valid log entry, the RP would have a higher degree of confidence that the certificate is genuine." But behavior of a log says nothing about whether a certificate was properly issued. A properly-issued certificate might be logged to a a misbehaving log, and a misissued certificate might be logged to a well-behaved log. Therefore, browsers should not consider a certificate more likely to be genuine just because it's logged, and if a certificate contains an embedded SCT from a log that's known to be bad, the browser should reject only that SCT, and still check SCTs from other logs. And there is no need to revoke a properly-issued certificate just because it's submitted to a log that misbehaves. Section 5.3 says that "evidence of a bogus or erroneous certificate" can be "in the form of a log entry and/or SCT." An SCT is irrelevant for this, as it attests only to log behavior. C. Response to log misbehavior On pages 4, 9, and 13, the draft says that monitors should not "trust" or "rely upon" misbehaving logs. But monitors don't trust or distrust logs - they just view logs as a source of certificates. Browsers, on the other hand, do trust and distrust logs. For example, after two logs (WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but Cert Spotter and crt.sh continued monitoring them until they shut down. The document should be updated to remove mention of monitors trusting or relying upon logs, and to make clear that the primary response to a misbehaving log is for browsers to distrust it. D. Signature/chain mutation attack There's another way a log can misbehave which ought to be mentioned in section 3.1.1.2. A misbehaving log that conspires with a CA could log a misissued certificate, but mutate the certificate's signature or chain such that the certificate is no longer cryptographically attributable to the CA. The CA could then plausibly deny that it issued the certificate. Since the signature and chain are not part of the Merkle Tree, the SCT will be accepted by browsers and be auditable, despite the log entry being mutated and useless for responding to the misissuance. Monitors should be sure to validate the signature and chain of logged certificates so that this misbehavior can be detected. E. Chrome is requiring SCTs now As David A. Cooper pointed out, Chrome is now requiring new certificates to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates. F. Organization The organization of the draft seems sub-optimal. At a high level, the document is broken up into semantic and syntactic misissuance, and then into malicious vs non-malicious CA. Within these categories, the document discusses the implications when the certificate is logged, not logged, or when the log is misbehaving. Very often, these implications are the same regardless of the type of misissuance or the culpability of the CA. As a result, there is a lot of duplication, often with minor differences in wording, which makes the document harder to understand. I think the structure of section 5, which discusses issues as standalone concepts, is a better model. Alternatively, the duplication could be re
Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
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 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: 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. 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. 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 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." 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? 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
[Trans] WGLC started for draft-ietf-trans-threat-analysis
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 Paul & Melinda ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
