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

[Stephen Kent <[e-mail]>]

Ryan,
>
> 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 federal PKI doc has nothing to do with any of what I wrote. Not sure 
why you bring it up here. It too is not an RFC, so ...
> 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 -
As I tried to say other responses, this document is NOT intended to 
reflect running code. It is intended to reflect the security features 
and residual vulnerabilities of CT as described in 6962-bis. That is an 
appropriate scope for a threat/attack analysis RFC, i.e., it is based on 
a system description as provided in another RFC. When 60962-bis is 
updated to reflect experience gained from deployment, this threat/attack 
analysis should be updated, or become obsolete. RFC 8211 performs this 
sort of analysis for CAs and repository managers in the SIDR context.

One can generate an description of cert processing based on deployed 
code in a context. The recently approved SIDROPS doc 
(https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/) 
is a good example. One could augment that description with a security 
analysis. They both make reasonable Informational RFCs, but they are 
different from an analysis based strictly on what is documented 
standards track RFCs.

>>     [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.
agreed
> 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.
>
agreed
> 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.
I have revised the text discussing revocation on page 4 as follows: " 
Certificate Revocations Lists (CRLs) [RFC5280] and the Online 
Certificate Status Protocol (OCSP) data [RFC6960] are the primary  
certificate revocation _mechanisms_ established by IETF 
standards.Browsers may make use of proprietary mechanisms to effect 
revocation status checking, in lieu or in addition to the mechanisms 
noted above."

I also revised the later sentence to say: " As noted above, browser 
vendors may employ proprietary means of ..."

>>     [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.
Good point- paragraph 3 does say that _anyone_ concerned about 
mis-issuance can monitor logs. I have the following note after the cited 
sentence: " (Note that [I-D.ietf-trans-rfc6962-bis] notes that anyone 
can elect to monitor logs for mis-issuance, indicating that there is a 
potentially larger, unspecified set of beneficiaries.)"
>
>
>>     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.
I have revised the text to say: " If an RP _acquires and verifies an 
inclusion proo_f for a certificate that claims to have been logged has a 
valid log entry (8.1.4 in [I-D.ietf-trans-rfc6962-bis]), the RP probably 
would have a ..."
>
> 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.
Is it accurate to say that read-only logs (aka Log caches?)  would 
address the privacy concern only if there are a lot of them, perhaps 
locally operated? Any individual Log cache could still track queries 
from browsers and thus pose a potential privacy violation, right? So, 
the real issue here seems to be creating Log caches that a set of users 
accessing a cache can be comfortable with the cache in question. That's 
a lot of detail that is not even hinted at in 6962-bis. The description 
of Log operation and the Log interface both discuss submission of certs 
or pre-certs, neother of which is relevant for a Log cache. If 6962-bis 
anticipated Log caches, one would expect such caches to be described, 
with a note that such caches offer a reduced interface (no submissions), 
and that they need to be distributed in way that avoids privacy 
concerns. Since NONE of that is mentioned in 6962-bis I don't think this 
analysis has to presume that such read-only logs are part of the design.

I agree that 6962-bis does not preclude the creation of read-only logs, 
but since 8.1.4 explicitly notes that fetching inclusion proofs from a 
Log represents a possible privacy concern, I think it fair to echo that 
concern here.
>
>>     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.
Yes, it's because 6962-bis says SHOULD, not MUST. Whenever an RFC says 
SHOULD, it allows a compliant implementation to not implement the 
associated requirement. It is preferable that an RFC explain the 
criteria that motivated authors to make a requirement a SHOULD vs. a 
MUST, but I admit that this is often not done in many RFCs.
>
>>     [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.
I agree that the cited paragraph describes logs as a means for detecting 
mis-issuance. But, 3.1 says " ...
it is expected that certificate issuers and subjects will bestrongly 
motivated to submit them." Also, the sentence immediately before the one 
you cites says: "Logging enables a Monitor to detect a bogus certificate 
..." so I don't think there is much confusion here. Nonetheless, I have 
revised the cited sentence to read: "Logging of certificates thus helps 
to deter mis-issuance ..."

>>     [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.
6962-bis does not specify Monitor behavior in the circumstances we're 
discussing, so there is no definitive guuidance here, but I have deleted 
the sentence in question.

>>     [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.
I agree that submissions to logs from other, unspecified entities is 
explicitly allowed by 6962-bis, but I think this is mentioned only once. 
I see one mention of the downside of relying on an SCT embedded in a 
cert, in the third bullet of Section 6. If there was strong feeling 
about superiority of the first two options, 6962-bis could have made 
them MUSTs and the cert extension a MAY, but it didn't.

Nonetheless, the text does indicate the benefits for a Subject if it 
chooses to submit it's cert to a Log, So Figure 1 will become 1a, and be 
labelled " Data Exchanges Among CT System Element (CA submission)"

Figure 1b  will be labelled " Figure 1b: Data Exchanges Among CT System 
Elements (Subject submission)" and will show a Subject submitting cert 
chains and receiving an SCT and, optionally, and STH.
>
>>     [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.
Your comment referred to the "stated goals of CT" but 6962-bis does a 
poor job of clearly stating goals. I once posted the cited statement to 
the TRANS list and asked Ben is he disagreed. He did not disagree, but 
the statement didn't make it into any of the many revisions of the 
document. I changed the sentence to read: " As noted above, the goals of 
CT appear to be to..."
>
>>     [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.
I acknowledge that SETs can pose a problem in some cases, depending on 
the SET elements. I believe that "standard" extensions in X.509 certs 
don't trigger such problems. The issue you raise seems to result from an 
ambiguity in the requirements imposed on Logs; 6962-bis requires that 
Logs verify the cert path for a submitted chain. It allows Logs to 
ignore expiration dates and revocation status, but the phrase "not fully 
valid according to RFC 5280" is too ambiguous to be helpful.
>
>     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.
I forgot about the "bad certificate" error message. This further 
confuses the question what a Log MUST do when processing a submission. 
If a Log computed the hash value of each cert, as delivered, w/o 
checking or re-encoding to DER, then the ambiguity re SETs might cease. 
But, under that ssumption, the "bad certificate" error would never be 
returned- it error clearly indicates DER checking by a Log. The "bad 
submission" error message says that the cert or pre-cxert is not "valid" 
without any cleart indication of what constitutes validity (seperate 
from a bad cert chain, which is a seperate error message. I'd like to 
understand how to interpret these error messages, and the text in 4.2, 
in a consistent fashion.

In the meantime, I have changed the sentence you cited to read: " So 
creating a log entry for a fake bogus certificate _suggests that the log 
may be misbehaving._
>
>>     [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.
>

Ad noted above, Figure 1 is being replicated and modified to address the 
omission of Subjects as submitters. I have changed the sentence in 3.2.1 
to read: " If the CA (or Subject) does not submit..."

I do not agree with your contention that the analysis is based on an 
unspecified profile of 6962-bis. 6962-bis has a lot of ambiguities, some 
of which we have discussed above. The analysis tries to explore the 
vulnerabilies that can arise because of these ambiguities, not as a 
result of implementation errors, but because implementations of CT 
system elements could comply with 6962-bis and not behave in the fashion 
that one might hope.

Steve