Re: [Trans] responses to Ryan's detailed comments on draft-ietf-trans-threat-analysis-15

[Ryan Sleevi <[e-mail]>]

On Tue, Sep 25, 2018 at 2:42 PM Stephen Kent <[e-mail]> wrote:

> Ryan,
>
> Below are responses to your detailed comments. Also, I looked at the first
> version of this document, when it was accepted by the WG, in June 2015, and
> it used the same taxonomy. So, it has been over 3 years since the document
> structure was adopted.
>
> [Page 2]
> 1. Introduction
> > Subjects are web sites and RPs are browsers employing HTTPS to access
> these web sites.
>
> While only present in the introduction, this definition of RP is overly
> narrow, and perhaps not aligned with its common usage. There is the RP as
> the human user, and the RP as the software performing the validation. The
> definition here focuses only on the latter, and yet conflates the benefits
> received with a definition that includes the former.
>
> I have changed to text to reflect that RPs are *users* of browsers ...
>
> This doesn’t seem correct, because many of the benefits of CT are derived
> not during the processing and validation of certificates by software, but
> by the human users that are relying upon that software. If we take a purely
> programmatic approach to validation, then that would suggest CT does not
> benefit OV/EV certificates, nor their named Subjects, since that
> information is not used by browsers to access HTTPS. However, because the
> value of that information is nominally in that human users rely on it, it
> seems we really have a fourth category of beneficiaries to consider -
> end-users.
>
> The changed definition of RPs now refers to users, addressing your concern.
>

Unfortunately, based on the subsequent discussion about the exclusion of
vendors, I disagree that it addresses the concern. Keeping a tripartite
system is, I believe, a significant oversight of any meaningful threat
analysis document, because it ignores an entire beneficiary - either users
(in the original) or, subsequently, PKI operators.

To use terminology from RFC 3647, this distinction is made between relying
parties and relying party applications, or, more aptly, "the entity
controlling or coordinating the way relying parties or relying party
applications use certificates" (Section 3.1)

> [Page 3]
> 1. Introduction
> > When a Subject is informed of certificate mis-issuance
> > by a Monitor, the Subject is expected to request/demand
> > revocation of the bogus certificate. Revocation of a
> > bogus certificate is the primary means of remedying
> > mis-issuance.
>
> One of the substantial ways that CT has improved the ecosystem is through
> its ability to detect misissuances by CAs - regardless of syntactical or
> semantic, perhaps best demonstrated through [4]. This paragraph overall
> only focuses on the risk to Subscriber’s through actively issued
> certificates in their name, while all Subscribers (of all CAs) benefit from
> having a consistently applied and enforced set of standards. This is most
> likely a result of failing to consider trust store vendors as a distinct
> category from relying parties (whether software or human users), or perhaps
> prematurely aggregating them with Monitors.
>
> I agree that the ecosystem  can  benefit overall from CT. I am aware of no
> definition of a "trust store vendor" in 6962-bis, nor in any TLS spec, nor
> any other RFC. I assume the term applies to a set of parties who curate
> sets of trust anchors that are made available to RP software, right? Given
> that there appears to be no characterization of such vendors in IETF docs,
> I am not inclined to expand the set of CT system elements to add them at
> this stage.
>

I disagree with your assessment that this does not participate in the
discussion. Since you've adopted a more liberal (although unfortunately for
the rest of the document, fairly meaningless) discussion of PKI in the
abstract, this is arguably the PKI policy management authority (NIST SP
800-32), which is referenced within RFC 3647. The problem with the adoption
of the general term PKI is that it leaves it ambiguous whether you're
discussing a PKI operated within a single organization or a federated PKI.
A "trust store vendor" - in this case, an entire community of suppliers
being dismissed - is, in 3647 terms, the PKI participant itself that
determines the which sets of PKIs to federate with based on the evaluation
of those other PKI's CP/CPS.

Alternatively, we can use the definition from RFC 6024, and take the view
that this is a "trust anchor manager" that is the entity responsible for
managing the contents of a trust anchor store.

I can understand and appreciate hesitation to add them at this stage - as I
acknowledge, getting this document into a state that reflects running code
is a substantially larger undertaking, and rough consensus has, from the
archives at least, been a questionable part through every major milestone -


> [Page 3]
> > Throughout the
> > remainder of this document references to certificate revocation as a
> > remedy encompass this and analogous forms of browser behavior, if
> > available.
>
> While this is located within the introduction, this seems to setup an
> assumption that ‘revocation’ refers to specific certificates or to the
> combination of Issuer Name and Serial Number. This can be seen later in the
> document, most notably in the contentious Section 3.4, but doesn’t reflect
> the practiced capabilities of clients. This, like the most discussion
> preceding this, is a result of an unclear focus as to what the Web PKI
> constitutes, and whether this document views such revocations (of SPKI) as,
> well, revocation. To the extent the document relies on revocation as a
> remedy, it may be worthwhile to either split out and discuss different
> approaches to revocation that have been practiced - which include by SPKI,
> by Issuer & Serial Number, by Subject Name and SPKI - since these seem to
> materially affect the subsequent discussion of threats and remediation.
>
> I broadened the discussion of browser revocation mechanisms to accommodate
> a comment from Rich, despite the lack of any IETF documentation on such
> proprietary mechanisms. I don't want to devote more text to describing such
> mechanisms.
>

Then there's a consistency issue with 5280. CRLs and OCSP are described as
revocation mechanisms, rather than revocation itself. Clearly, CRLs as
specified by 5280 are not the only revocation mechanism, as OCSP provided
another means of revocation. If the view is that these are the only two
mechanisms, Section 3 of 5280 acknowleges that revocation may be provided
by some other mechanism, and doesn't normatively specify revocation as
being Issuer and Serial.

If the view is that this threat analysis only covers CRLs and OCSP as
specific revocation mechanisms, it seems it would benefit from clarifying
that. Alternatively, if revocation is to be used in the sense of RFC 5280,
then what we're discussing here is that different revocation mechanisms may
have different tradeoffs, regardless of the degree of IETF specification.


> [Page 3]
> > A relying party (e.g., browser) benefits from CT if it rejects a
> > bogus certificate, i.e., treats it as invalid.
>
> While understandably the introduction is trying to be brief, it ignores
> the substantial primary benefit already being derived by multiple browsers,
> which is the benefit to ecosystem analysis. Whether this analysis is in
> assessing which CAs are responsible for which forms of misissuance [5] or
> about assessing compatibility risks, there are substantial benefits to be
> derived independent of the treatment of bogus certificates.
>
> yes, the intent in the intro is to be brief. But, there is also the issue
> that "ecosystem analysis" is an activity outside the scope of IETF
> standards, and it is not cited by 6962-bis as a motivation for CT.
>

I disagree with this summary. Section 1 of RFC 6962-bis does not limit the
parties who might be concerned about misissuance to only Subscribers.
Paragraph 3 explicitly explores this notion of ecosystem analysis.

> [Page 4]
> > and rejects the certificate if the
> > Signed certificate Timestamp (SCT) [I-D.ietf-trans-rfc6962-bis] is
> > invalid.
>
> On an editorial point, it seems this should be Signed Certificate
> Timestamp.
>
> Editorial, bit I fixed it.
>
> On a functional point, however, validity here is being left ill-defined.
> Validity here covers a spectrum including simply a Log not being recognized
> for that purpose, to being improperly syntactically constructed, to having
> an invalid signature, to having something wrong with the associated Log
> structure as a result of examining that SCT (e.g. no inclusion proof, no
> associated entry).
>
> see response below.
>
>
>
> [Page 4]
> > If an RP verified that a certificate that claims to have
> > been logged has a valid log entry, the RP probably would have a
> > higher degree of confidence that the certificate is genuine.
> > However, checking logs in this fashion imposes a burden on RPs and on
> > logs.
>
> Here, it’s ambiguous as to what “genuine” means, as this is the only
> occurrence in the document. It’s unclear if it’s meant to be an antonym to
> bogus (that is, semantic misissuance in the document’s terminology), or
> whether it’s also meant to include adversarial misissuance.
>
> Fair point- I changed "genuine" to "not bogus"
>
>
> It’s also ambiguous as to what the checking entails, since verifying the
> entry and its correlation to the certificate can be distinct from the
> verification of the inclusion proof.
>
> The text separately discusses SCT verification and verifying a valid log
> entry. The comment about checking for valid log entry refers to fetching an
> inclusion proof. I have changed that text to cite 8.1.4 in 6962-bis.
>

I think this is a good clarification, but the term "verifying the entry" is
still worth clarifying, because there's a distinction here between using
the API from 5.6 of 6962-bis and using 5.4 or 5.5 of 6962-bis, which is
what 8.1.4 refers to.

That is, you are not "verifying a valid log entry" by using the algorithm
in 8.1.4. You're fetching an inclusion proof. The precision here is
important and semantically different.

This is similar to the issue I raised above, with "is invalid", because it
leaves ambiguous whether only the output of 8.1.3 is considered, or if also
considering 8.1.4. Note also that the execution of 8.1.3 and 8.1.4 are
different, and, for a mitigation of this threat, both essential.

> [Page 4]
> > Finally, if an RP were to check logs for
> > individual certificates, that would disclose to logs the identity of
> > web sites being visited by the RP, a privacy violation.
>
> A potential issue with this construction is that it seems to miss the
> existence of read-only Logs - that is, Logs that mirror the full Merkle
> tree of the SCT-issuing log, and which can present proofs without having
> access to the primary Log’s key material.
>
> I don;t believe that 6962-bis describes read-only logs. As a resiult they
> are not considered as part of the analysis.
>

They're an implementation of 6962-bis. I fail to see the requirement that
they be called out as such in it, as it's possible to have another
operating entity operate a Log (including the RP) that fully conforms to
the relevant APIs being discussed here (8.1.3 and 8.14, presumably).

I raise this as an issue with the construction because it defines in
absolute terms that it's a privacy violation, yet there exist
privacy-preserving alternatives that fully meet what you're specifying in
the text here, without altering or changing the protocol.


> It’s unclear whether this is solely referring to online checking - that
> is, checking for inclusion proofs at time of validation - in which case, it
> seems like 6962-bis already discusses this point in Sections 6.3 and 8.1.4,
> along with privacy-preserving approaches. It’s unclear if this document is
> referring to something different, then, or if it’s rejecting both the
> documented alternatives and those discussed in the communities.
>
> 6.3 does not require a TLS server to send an inclusion proof. It says that
> "... if the TLS server can obtain them, it SHOULD ..." As a result, the
> analysis does not assume that a client will receive an inclusion proof from
> a TLS server.  6.3 says that sending inclusion proofs in the TransItemList
> structure helps protect client privacy- which is an admission that client
> fetching of inclusion  proofs may undermine client privacy. 8.1.4 notes the
> same client privacy concern. So, I don't see your point here. Are you
> saying that since 6962-bis warns about client privacy concerns and offers
> (but does not mandate) a way to mitigate these concerns, that the threat
> analysis ought not cite this concern?
>

If the view is that because it is a SHOULD, it should be read in RFC 6919
terms, I can appreciate that point, although disagree. My point is that
because it's a SHOULD, consideration in a threat analysis should be devoted
to exploring both possibilities in its analysis, and should presume that
the SHOULD will be the dominant interpretation, given RFC 2119's
interpretation.


> [Page 4]
> > Logging of certificates is intended to deter mis-issuance,
>
> I think this conflates detection with deterrence. While it’s true that
> detection can have a deterring effect, it seems more accurate to reflect
> that the purpose is detection, as reflected in the language choice 6962-bis.
>
> To which places in 6962-bis are you referring?
>

That deter does not appear at all within 6962-bis, but within the first
paragraph of Section 1, the Introduction, it spells out the goal of
mitigation through detection.


> [Page 5]
> > Monitors ought not trust logs that are detected misbehaving.
>
> I mentioned this in the high-level feedback, but this notion here about
> log ‘trust’ is one that deserves unpacking. Monitors have strong incentives
> to continue to examine certificates from Logs, even those that have been
> shown to be providing a split view. As it relates specifically to Monitors,
> however, they may not trust a Log to be a complete set of all issued
> certificates, but they can certainly trust a Log to contain interesting
> certificates, provided the signatures validate.
>
> We disagree about the use of the term "trust" here, but I have revised the
> text to note that "... misbehaving, although they may elect to continue
> to watch such logs."
>

We also disagree about what Monitors ought or ought not to do, which I
think this proposed change does not adequately address. I think it is
specifically bad advice, because monitors ought to consider such logs in
the consideration of detection and misissuance. There are a host of
pragmatic reasons for this, and I spelled out some above, but one that
might be relevant is that even if a log is detected as misbehaving, for
software not receiving updates, SCTs from this log may still be relied upon
as proof of disclosure, and depending on the nature of the misbehaviour,
it's still in the interest of clients to monitor.

> [Page 6]
> Figure 1
>
> I think this figure is misleading or inaccurate, particularly around steps
> 1-5. This approach manifests in some of the later discussions around syntax
> checking of Logs, but as it relates to this specific figure, misses out on
> the potential parties that are performing the certificate logging. There’s
> no requirement, in 6962, -bis, or as practiced, to require a CA to log 100%
> of its certificates, so Steps 1-5 are more complicated. This can be seen in
> existence today, as large organizations like Google and Cloudflare perform
> the logging and inclusion operation themselves, both for new and existing
> certificates.
>
> As noted above, current practice that is not mandated by 6962-bisnot
> considered in this analysis. You are correct that 6962-bis does not require
> that a CA submit all certs that it issues to be logged, but 3.1 notes that
> any cert not logged may be rejected by a TLS client, and states that this
> provides string motivation for a CA to log all certs destined for
> consumption by such clients.
>

I do not believe this response adequately addresses the feedback. Further,
I do not believe the text cited supports the interpretation being argued
here, particularly since 3.1 specifically notes that any entity can submit
a certificate, and ignores the second part, which is "and subjects" will be
motivated to submit them.

It seemingly ignores the motivations in Section 6, which also notes that a
risk is entailed by the CA embedding, and that other solutions mitigate
this risk.

As I said, I think this figure is misleading or inaccurate - it's only
covering part of the logging flow, which is the part with the most risk,
and the subsequent discussion seems to hinge on expecting this is the only
logging flow.


> [Page 7]
> 2. Threats
> > As noted above, the goals of CT are to deter, detect, and facilitate
> > remediation of attacks that result in certificate mis-issuance in the
> > Web PKI.
>
> I do not believe that aligns with the stated goals for CT, which is about
> detection. Deterrence and remediation are important, but in the
> intersection of policy and technology, it's important to recognize that CT
> cannot and does not try to fix everything related to PKI.
>
> I hope we both agree that it would be preferable if 6962-bis explicitly
> stated its goals. We both agree that detection of bogus cert issuance is
> central to CT. Log entries provide the identity of a CA that mis-issued a
> cert, which facilitates remediation, e.g., when a Monitor detects a
> conflict with a cert of interest. Logging deters CAs from issuing bogus
> certs. I'll reword the sentence to say that the goals of CT *appear to be*
> .
>

I do not believe this addresses the comment, and I do not see how this
reply is consistent with the above remarks that rely on exact textual
references in 6962-bis or related IETF RFCs in order to be considered for
inclusion.

> [Page 10]
> > So creating a log entry for a
> > fake bogus certificate marks the log as misbehaving.
>
> Again, the terminology issues rear their head, in now we have to consider
> fake-bogus and real-bogus in interpreting the scenarios. Fake-bogus is
> clarified as those that haven’t been issued by the indicated CA, but the
> method of that creation of a fake is ill-defined. It seems we’re discussing
> “certificates whose signatures don’t validate,” but that’s not necessarily
> indicative of Log misbehaviour. As a demonstration of this, consider an
> implementation that performs BER decoding of the TBSCertificate, re-encodes
> it in DER, and compares the signature. If the CA has syntactically
> misissued in the classic sense - that is, rather than the document’s
> broader definition, focusing purely on X.509 and RFC5280’s DER-encoding of
> the ASN.1 - then it’s possible that the signature is over the malformed
> BER-data, not the (client re-encoded) DER-data. That the Log accepted the
> signature over the raw value of the TBSCertificate is not indicative of Log
> misbehaviour.
>
> The cert is broken if the signature was generated incorrectly by the CA.
>

I'm afraid you missed this point.
https://www.ietf.org/mail-archive/web/pkix/current/msg33308.html captures
one such discussion, but I seem to recall (and can spend more time digging
up) older conversations in PKIX around this point.


> Section 4.2 of 6962-bis says that a log MUST NOT accept a cert that does
> not chain to am accepted trust anchor. So, if it accepted the cert, the log
> acted in error (because it would have to validate the sig in each cert
> during the chain verification). I agree that this is a syntactic error by
> the log, in the traditional sense, but it is also an example of a log
> misbehaving, in any case.
>

We disagree then.


> Similarly, there are CAs that have, in various ways, botched the Signature
> or SPKI encoding in ways that clients understand and compensate for -
> unnecessary or omitted ASN.1 NULLs are my favorite example. That a Log
> understood this compatibility behaviour and accepted the certificate is not
> indicative of Log misbehaviour.
>
> 6962-bis allows a log to be sloppy about syntax checking relative to 5280,
> in Section 4.2.  But I interpret the initial requirement to verify the
> chain of sigs to supersede the later "flexibility" stated in 4.2. This is
> another example of ambiguity in 6962-bis leading to uncertainty in
> analyzing residual vulnerabilities.
>

In the above described scenario, in all variations, the log is fully
conforming to (differing) interpretations of RFC 5280, either with respect
to Section 4.2 or with respect to Section 5.1.1.3. These aren't minor
wording qubbles - these are positions that major (non-interoperable)
implementations have staked hills on to argue for or against various
interpretations. And while there's a 'common sense' interpretation, it's
one that I think is consistent with 6962-bis Section 5.1, which permits
logging even if poorly encoded.


> [Page 11]
> 3.1.2.  Certificate not logged
> > If the CA does not submit a pre-certificate to a log, whether a log
> > is benign or misbehaving does not matter.
>
> This is problematic in that the assumption here is that CAs are the ones
> performing the logging. Throughout the document, the description of CAs
> performing logging ignores the ability of Subscribers and certificate
> holders to perform the logging at their discretion, up to and including
> seconds before performing the TLS handshake. As a consequence, it misses an
> entire class of attacks that can arise when an inclusion proof for an SCT
> can not be obtained to an STH, because the SCT is newer than the published
> STH.
>
> I believe this is another instance of a compelling reason to re-evaluate
> the ontology of attacks and to not attempt to classify them using a
> hierarchy.
>
> Although 6962-bis does allow any entity to log a cert, the focus of the
> doc is very much on CA-based logging, as evidenced by pre-cert logging. No
> changes made.
>

Thanks. I'll stop my analsysis at this point, as I think it fundamentally
alters the subsequent conclusions that if we're not able to reach consensus
on this point, it does not seem that there's much value on proceeding
further. The entire analysis and threat model is undermined, in my view, to
the point that it no longer accurately reflects 6962-bis as specified, but
rather, an unspecified profile of it.

>