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