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

[Ryan Sleevi <[e-mail]>]

Thanks for the replies, Stephen.

Given the disagreements in interpretation and application of 6962-bis, it
sounds like this document should not progress until we've resolved those
matters in 6962-bis. Does that sound like a reasonable path forward? I
don't feel comfortable that this document describes the running code, and
I'm hesitant to believe we'll get rough consensus because of it, so that
might be a worthwhile path forward here.

Given the issues Andrew has pointed out, which I'm largely agreeing with or
contextualizing, would you feel comfortable proposing changes to 6962-bis
on areas you feel it disagrees with the feedback, or is that something that
you would feel more confident if Andrew and I do? If they are accepted,
would you feel comfortable making these changes to the threat document?

As it stands, I don't feel like the threat document is reflective of intent
or practice, and that leaves me a bit concerned about its general utility
for future readers.

On Mon, May 21, 2018 at 2:05 PM, Stephen Kent <[e-mail]> wrote:

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