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

[Stephen Kent <[e-mail]>]

Ryan,
Thanks for the comments, despite by unformatted reply to Andrew. Responses to your comments are inline below.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 14, 2018 9:06 PM, Ryan Sleevi <[e-mail]> wrote:

> On Mon, May 14, 2018 at 11:26 AM, Stephen Kent <[e-mail]> 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.

Please remember that the text I cited is from 6962-bis. It is that text that makes it optional for logs to perform syntax checks. I believe your comment on this should be directed to the authors of that document, not to me.

>
>
>> 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 understand the argument that logs ought to not perform any syntax checking behind what is needed to verify a signature chain. But, the text in 6962-bis doesn't say that, so, again, your complaint seems more appropriately directed at that document.

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

I didn't say that "or both" does not reflect reality. I said that it makes no sense grammatically :-). Typically the phrase "or both" refers to two antecedents, e.g., A or B or both. In the sentence I cited from section 8 of 6962-bis can you identify the antecedents? I can't. I find it very confusing.

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

The text in 6962-bis describes potential syntactic deviation from 5280 as quirks that need to accommodated by CT, not me. I agree that catching syntax errors by CAs, and providing an incentive for them to rectify such errors is a good goal. That could be accomplished several ways. For example, a log could refuse to use an SCT, making the cert less trustworthy to browser clients, and using an error message to there submitting CA. Or, a log could make an entry for the cert, generate an SCT, but return it with an error indication. Logging the certs, retiring an SCT, and providing no error feedback, seems to provide the least help in rectifying. the problem.

>
>
>> 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 goals of 6962 (and, through proxy, 6962-bis) is to detect and publicize any CA with such quirks, such that relying parties can move to distrust or otherwise restrict such CAs.

I think David Cooper's message suggests that CA "quirks" have not been uncommon, at least not historically. I recall when a widely-used (on mobile devices) browser failed to require the CA Boolean for a v3 cert purporting to be associated with a CA. This was a serious vulnerability that was exploited. If certs from the offending CAs were rejected by all browsers, the offendingCAs would have been forced to fix the problem. But, that was not  the case. The major browsers (Chrome, IE, Safari, Firefox, Opera) have not been very diligent about rejecting certs that deviated from 5280 specs. My guess is that no vendor wanted to become potentially less attractive to users by being there first (only?) to enforce such requirements. This may get better over time, but ...

>
>
>> 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.
>
> As mentioned, I think syntax checks should be SHOULD NOT. I only hesitate to say MUST NOT because I think that requires normatively specifying that few syntax checks that are necessary for spam/abuse prevention (for example, checking the basicConstraints bit on the issuer, so that anyone with a leaf can't just spam), and the ecosystem is still working through them.

Again, your suggestion for a SHOULD NOT ought tin be directed to 6962-bis, not to this document. My analysis is based primarily on what 6962-bis does or does not require of compliant CAs, logs, clients, Monitors, and Auditors.

>> I agree that a browser placing greater trust in a certificate because it has been logged is not fool-proof. However, it represents an important initial check. I believe Richard Barnes made some good arguments on the list last year about the utility of logging and the complexity and potential privacy issues that arise if browsers engage in auditing. So, yes, I believe that receipt of a certificate containing an SCT probably will inspire greater confidence. I will revise the text to insert the term "probably". Browser interactions with an audit system are not yet standardized and present some privacy concerns, so one ought not assume that the more extensive checks you note will be widely deployed.
>
> Like Andrew, I share these concerns about misplaced trust.

I don't dispute the fact that a more thorough checking of SCTs would be beneficial, but 6962-bis does not even require a client to fetch an inclusion proof (see section 8.1.4). Also note that Section 8.1.6 says that what a client has to do to satisfy "compliance" and what it does in the face of non-compliance is largely a local matter.

>
>
>> 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.
>>
>> A monitor selects a set of logs that it will use to check for mis-issued certificates. By so doing it is implicitly trusting (relying on) them. If they are detected to misbehave, Monitors will, presumably, stop relying on them, as you indicated in your example.
>
> I fear this may misunderstand or misrepresent one of the goals of CT. A monitor fully can continue to trust and rely on WoSign and StartCom logs (in this example) as sources of logged certificates. While it may not be a comprehensive view - that is, such logs may be omitting certificates - from a monitor perspective, that does not alter or undermine the purpose and value of the log, particularly for detecting misissuance.
>
> A log is not necessarily expected to contain all certificates in existence. Consider the set of logs we see these days that adopt policies in which they will only accept certificates with validity periods in defined bands, which beyond providing a defined lifetime of operation, also helps bound growth. There's no reason to suggest or believe these logs become any less useful once their issued certificates expire - for example, as ways of analyzing past CA malfeasance ("quirks", but really "security bugs"). The same way applies to logs that misbehave.

I don't see how your observations above relate to my comment that a Monitors relies on (trusts) the logs that it chooses to check. Can you cite text in 6962-bis that states what you characterize as the goals of CT relative to Monitors?

>
>
>> 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.
>>
>> I don’t think I understand the attack. Where is the mutated certificate signature? If you can provide a clear, detailed description of the attack I could include it in the revised text.
>
> Within the entry itself, as part of the proof of issuance to a CA.

I need a more complete description of the attack it if is to be included in this doc.

>
>
>> 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.
>
> This remains one of the biggest challenges to providing a more meaningful review at this time, and is worth considering as good feedback.

The overall structure of this document has been unchanged since it was submitted as a -00 draft in June 2015. A suggestion to restructure would have been appropriate two or three years ago, but not now.

Steve