Ryan,
With the publication of -15, and with the Chairs suggesting [1] again
[2] that it's appropriate to take a thorough review, I've tried to
review this doc in full again. Pre-emptive apologies if the format has
messed up, and my kingdom for a decent review tool to leave these more
mangably inline. Apologies for the delays, as I work to translate my
notes in the margin into concrete and actionable feedback,
suggestions, and hopefully productive explanations of the concerns and
considerations.
In the same spirit of your thanks to me for the work involved in
creating this threat analysis doc, let me thank you for taking the time
to provide many detailed comments on that doc.
At a high level, I think it’s worth echoing the concerns Andrew Ayer
raised on 2018-05-07 at [3]. Specifically, Andrew highlighted that the
document’s structure, and attempted hierarchy, leads to some
duplication of information and potential understating
culpability/threats. I think this remains accurate, and the suggestion
to focus on describing the attacks still seems a worthwhile
consideration. I believe that such an attempt would likely be able to
resolve a number of comments below, which appear to be the result of
trying to coerce the threats into the hierarchy.
As I noted in my reply to Andrew, the structure of the document has been
fairly constant for over 2 years. It's unreasonably late in this process
to suggest restructuring. I believe Eric Rescorla (the cognizant
Security AD) indicated that, at this stage, changes to the document
should be limited to addressing errors, not editorial issues, including
the overall structure.
I'll respond to your detailed comments, in my next message, but I do not
intend to make changes to the document structure, unless EKR revises his
earlier guidance.
With such a restructure, I think it’d be useful to avoid
discriminating based on syntactic and semantic mis-issuance - which is
the foundation for this documents hierarchy. The document establishes
the semantic mis-issuance is a misleading Subject or Subject
Alternative Name, while everything else is syntactical. However, this
understanding of syntactical misissuance muddies the waters between
what historically has been syntactical issues - e.g. BER encoding
instead of DER - and what’s been seen as a semantics issue, such as
granting a capability or extended key usage without the appropriate
procedural controls or validation.
In the context addresses in 6962-bis, the fundamental semantic issue for
a cert is ensuring that the Subject identifier accurately represents the
holder of the private key. In some other contexts a cert may represent a
capability (in the traditional, computer security sense), but that's not
the primary focus here.
The early emphasis on syntax and semantics causes a whole class of
adversarial models to be missed, ones which have been the forefront of
concerns from existing Log operators and CT consumers. Such attacks
include the ‘malicious’ logging of certificates - that is, syntax and
semantics that are fully conforment with the relevant profiles, but
which a Log may find undesirable to provide in an append-only record.
For example, certificate extensions with ‘objectionable’ content
provide such a model.
I was wondering what is "objectionable content" is in this context, but
upon reading your detailed comments the example you provide seems to be
inclusion of libelous text as a cert extension. No, the document does
not address that sort of attack.
Another attack that is omitted includes that of denial of service
through ‘flooding’ - an issue that has seen more than one Log struggle
to keep up - in which the existing corpus of certificates not present
within a given Log are suddenly presented to that Log. This same
adversarial model applies to revoked certificates, particularly
revoked CA certificates, in that they allow for large corpora of
certificates to be created, potentially with problematic content, and
be submitted to Logs.
I found only one comment in 6962-bis about DoS via flooding wrt
submissions, in 4.2. It appears that a log could reject/delay a
submission if it is busy, without violating 6962-bis, but I agree that
the spec is not very clear on that topic. 4.2 specifically notes that a
log could reject submissions to counter flooding attacks. Ultimately,
if a log operator cannot offer a robust processing and communication
capability, it probably it ill-suited to act in that capacity. This
might be a good example of where 6962-bis could have provided useful
guidance, but ... Nonetheless, I have revised the abstract to note that
DoS attacks are not considered to to emphasize that 6962-bis is the
primary reference:
"This document defines an attack model and discusses threats based on
the system design presented in [I-D.ietf-trans-rfc6962-bis]. It analyzes
potential vulnerabilities associated with that design, and considers
compromises of system elements and malicious behavior by such elements.
It does not consider implementation vulnerabilities, including ones that
might enable denial of service attacks against these elements."
Similarly, this treatment of syntax and semantics leads to suggestions
that would actively undermine some of the goals of Certificate
Transparency. In particular, the suggestion of CT logs performing
syntax validation has, in the discussions previously, been pointed out
that it hinders, rather than helps, transparency, in that it allows
for an entire class of syntax violations to be swept under the rug by
colluding Logs, preventing transparency around the CA’s operations.
This fundamentally redefines the goals of Certificate Transparency, in
a way that is inconsistent with its widely-deployed usage among root
programs to supervise participants and review CA operations, and it
would be a mistake not to mention this.
As noted above, the threat analysis is based primary on what 6962-bis
mandates as requirements, and what it fails to mandate. That approach to
a threat/attack analysis is typical for an RFC. As I noted previously,
IF 6962-bis stated that logs are precluded from checking syntax, then
there would be no discussion of the implications of such checks in my
document. But, that's not the case. What may be common practice in the
current deployment environment is not relevant to an analysis based on
what the defining CT document says (and fails to say), in the same sense
that flaws in current implementations are not part of such an analysis.
Another high-level point is that the document makes heavy use of
parentheticals. While clearly my own writing is just as guilty of
this, although perhaps through abuse of hyphens and commas, I think
many of the parenthetical remarks fall into categories that either
derail the discussion at hand with asides and speculation, or which
should otherwise be appropriately integrated into the text and the
document structure itself. At times, there are even nested or unclosed
parentheticals, which stick out rather substantially.
The RFC Editor will ensure that unbalanced parentheses will be fixed.
However, the choice of parenthetical comments vs. using a hyphen is an
example of a style issue that is no longer appropriate for discussion.
One last high-level point, before the more detailed line-item
feedback, which is that this document broadly speaks to the notion of
“trusting” Logs, as if that is something that either Monitors or RPs
do. In particular, in the discussions about misbehaving Logs, it’s
frequently suggested that Monitors should not “trust” the Log, or
presents Log misbehavior as an ‘attack’ against Monitors. While it’s
certainly true that Monitors need to be careful in regarding what a
Log omits, there’s no risk or harm in examining what a Log includes -
indeed, it’s particularly beneficial to clients to widely consume data
from Logs, even those no longer recognized by CT clients for purposes
of SCT enforcement. Andrew touched on this in his previous reply, and
I don’t think draft-15 really meaningfully addresses that concern.
When a Monitor relies on a log to detect certs of interest, it is
trusting that log. But I agree that a phrase like "relies upon" is
preferable, and I will change the text accordingly. When an RP relies on
an SCT in deciding whether to accept a cert, it too is trusting the log,
but, as above I will review the text to see where this term should be
changed.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
