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 <a...@andrewayer.name> 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 184.108.40.206 and 220.127.116.11 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 18.104.22.168 is premised on two I-Ds that were not adopted by trans > > and have expired. > > I suggest that sections 22.214.171.124 and 126.96.36.199 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 188.8.131.52. 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 184.108.40.206, 220.127.116.11, 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 > > removed from sections 3 and 4 and replaced by references to prior > sub-sections. > > G. Minor comments > > Page 3 says "'bad-CA-lists' a CA as noted above". "Bad-CA-list" hasn't > > been defined and doesn't appear to be noted above. > > Page 3 talks about "validat[ing]" an SCT, which is ambiguous, as it > > could refer to checking the SCT's signature, or auditing the SCT for > > inclusion. I suggest replacing "validates" with "audits" and replacing > > "is invalid" (in the same sentence) with "fails auditing." > > Page 4 says that "a CA benefits from CT when it detects a (mis-issued) > > certificate that represents the same Subject name as a legitimate > > certificate issued by the CA." How is a CA supposed to know if the > > certificate is misissued or not? > > Page 10 says that a monitor/auditor will detect a misbehaving log when > > it "sees the bogus certificate." It also needs to see the SCT. > > Section 18.104.22.168 talks about a Subject being able to detect the lack of > > an SCT in a certificate that it is issued. Since this is part of the > > section on "Semantic misissuance," which is defined in the Introduction > > as a certificate issued to someone who isn't the Subject, it's unclear > > to me what the point of this sub-section is. A Subject, by definition, > > would never be issued a semantically misissued certificate. > > Section 3.3.1 ends with "If the bogus certificate is detected and > > logged, browsers that require an SCT will reject the bogus certificate." > > Wouldn't the logging of a certificate cause an SCT to be issued, and > > thus allow it to be accepted by browsers that require an SCT? > > The last paragraph of section 3.5 talks about the attack in 3.4 and > > should be moved. > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans
response to Andrews comments.pdf
Description: Adobe PDF document
_______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans