Re: [Trans] Review of draft-ietf-trans-threat-analysis-15

[Stephen Kent <[e-mail]>]

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