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

[Ryan Sleevi <[e-mail]>]

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.


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


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

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.

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.

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.


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


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