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

[Stephen Kent <[e-mail]>]

Ryan,

Responses inline

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 18, 2018 12:19 PM, Stephen Kent <[e-mail]> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On May 17, 2018 2:57 PM, Ryan Sleevi <[e-mail]> wrote:
>
>> On Thu, May 17, 2018 at 2:09 PM, Stephen Kent <[e-mail]> wrote:
>>
>>> Ryan,
>>> Thanks for the comments, despite by unformatted reply to Andrew. Responses to your comments are inline below.
>>>
>>>>
>>
>> <snip>
>>
>>>>> 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.
>>
>> Monitors watch logs to check that they (logs) behave correctly
>> Monitors watch logs for certificates of interest
>> Monitors watch logs both to check that they (logs) behave correctly and to check for certificates of interest.

OK, I now see why the “or both” makes sense, but it appears to be wrong J.

Both descriptions of Monitor operation in 8.2 say that step 4, checking for a certificate of interest, is performed “If applicable”. That implies that steps 1-3 and 5 are checking to see if a log is behaving correctly (in a very basic sense). So, it seems that Monitors are always checking logs for consistency, and optionally checking for certs of interest. If so, the opening sentence should say that Monitors watch logs to check that they behave correctly (in a basic sense) and, optionally, they watch logs for certificates of interest.

>>
>>
>>>>
>>>>
>>>>> 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.
>>
>> Right, I'm explicitly disagreeing with that position. I'm saying that Logs that refuse to issue an SCT actively harms the CT ecosystem and does not help the furtherance of the improving, at least, the Web PKI.
>>
>> From the point of view of RFC 6962 and RFC 6962-bis, it's not a protocol error for a CA to have submitted such a cert, so returning an error message for unrelated reasons seems to be the least helpful, in that it conflates two separate systems of concern.

(As an aside, I’m not sure what you cite 6962. It’s an experimental RFC that is Obsoleted by 6962-bis.)

Section 5.1 defines an error code “bad submission” that is sent if the submission is not a “valid” certificate or pre-certificate (see table on page 28). Since what constitutes a valid certificate is ambiguous (see my earlier comment about RFC 5280), I think this error code could be inapplicable in the case of a syntax 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 ...
>>
>> I'm not disagreeing that CA non-compliance to RFC 5280, which is a normative requirement of the Baseline Requirements, has unfortunately not been uncommon.
>> I'm saying it's not accurate to describe such non-compliance as a 'quirk' - a somehow benign deviance - when it is active misissuance and failure to abide by both stated and expected policy.

I agree that issuing certificates with syntax errors is serious, but the term “quirk” was chosen by the authors of 6962-bis, not me.

>> Regarding your view of diligence in rejecting such certs, I can't help but feel that's a non-sequitor in the context of CT. However, since this has been suggested a few times now as somehow a deficiency or non-conformancy on behalf of the browsers or RFC 5280 clients, recall the following:
>>
>> https://tools.ietf.org/html/rfc5280#section-6.1
>>    Therefore, the algorithm only includes checks to verify that the
>>    certification path is valid according to X.509 and does not include
>>    checks to verify that the certificates and CRLs conform to this
>>    profile.  While the algorithm could be extended to include checks for
>>    conformance to the profiles in Sections 4 and 5, this profile
>>    RECOMMENDS against including such checks.

The text you cite applies to certificate path validation. Other parts of 5280 define syntactic requirements for certificates

>> RFC 5280 is but one profile, and for a number of clients, they must deal with profiles for other constituencies - for example, local Enterprise-defined profiles.

I’m not sure what you point is here. I knew Jon and during my 10+ years on the IAB we (politely) disagreed about his mantra. I argued that being liberal in what one accepts is a dangerous strategy re security, despite from the perspective of interoperability.

>> While this is unquestionably symptomatic of the problems with the Robustness Principle, as Martin Thompson has so thoroughly explored in https://tools.ietf.org/html/draft-thomson-postel-was-wrong, it's worth noting that such criticism is a bit misplaced.
>>
>>>>> 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 I think RFC 6962-bis can benefit from improvements, to highlight that the syntactical checks, as interpreted by you, was not inline with the intention of syntax checks as written - that is, for example, ensuring an interpretable parsing of the Certificate into its corresponding tbsCertificate and signature fields, or the relationship of the tbsCertificate's issuer to the next certificate's subject, etc.
>>
>> That is, syntax is as minimal as necessary to ensure it's just not arbitrary random bytes being added to the log (as that presents an operational risk), but not to those matters of policy or profile enforcement explicitly recommended against by 5280.

If 6962-bis stated that logs MUST NOT check syntax beyond what is needed to perform certificate path validation, then we would not be disagreeing.

>>
>>
>>>>> 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.
>>
>> I'm not sure how this addresses or responds to the concerns?

The abstract for 6962-bis says: “The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.” This text suggests that the goal is for browsers to distrust certificates without SCTs. To me that suggests that the authors believe that a browser ought to view a certificate with an SCT as more trustworthy than one without, even if the browser performs no additional checks.

>>
>>
>>>>> 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?
>>
>> I'm not sure how you're arriving at a conclusion that there's either reliance or trust involved here on the part of monitors, so that may be the heart of the confusion.

There is no requirement that any Monitor watch all logs. Thus, when a Monitor elects to watch a set of logs it is relying on them as it tries to perform it’s optional task  of watching logs for certificates of interest for the clients of the Monitor. This seems consistent with the text in Section 1 (6962-bis): “Those who are concerned about misissuance can monitor the logs, asking them regularly for all new entries, and can thus check whether domains for which they are responsible have had certificates issued that they did not expect.” If a Monitor is associated with a CA, the choice of logs may be different; the CA would certainly watch the logs to which it submits its certs to receive SCTs. But it also may watch other logs to detect certificates issued under the same name as certificates that it has issued (to protect its clients).

>>
>>
>>>>> 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'm not sure how to further expand on this, as this is a rather complete and comprehensive description. Perhaps Andrew could reword it, but in terms of informational content, it's fully descriptive of the risk - a log and a CA conspiring using unauthenticated data that is still relied upon by monitors.

If you look at the descriptions of attacks involving a malicious CA and a misbehaving (or compressed log  in 3.2.1.2 and 3.3.3) they provide a lot of detail, compared to the very terse statement above.

Steve