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

[Ryan Sleevi <[e-mail]>]

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.


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


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


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


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

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.


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


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