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

[Stephen Kent <[e-mail]>]

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 <[e-mail]> 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 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 3.1.2.1 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
> 
> [e-mail]
> 
> https://www.ietf.org/mailman/listinfo/trans