Ryan,
Responses inline
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 18, 2018 12:19 PM, Stephen Kent <[email protected]> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On May 17, 2018 2:57 PM, Ryan Sleevi <[email protected]> wrote:
>
>> On Thu, May 17, 2018 at 2:09 PM, Stephen Kent <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/trans
