Matt,
Thanks for the review and comments.
2.1.1.2. Malicious or conspiring log
In this case, the bogus (pre-)certificate has been submitted to one
or more logs that are either simply malicious or are conspiring with
the attacker. It is assumed that the logs issue SCTs (in an attempt
to fool browsers and/or Monitors). In this context, a log probably
will suppress a bogus certificate log entry. (This case encompasses
the scenario in which a log creates an entry for the certificate but
reports it selectively.)
Do you have any thoughts on what a "simply malicious" log might look like,
behaviourally speaking? Is there a way to differentiate, from the outside,
whether a log is "simply malicious" or "conspiring"? Do we even care that
there's a difference?
probably not. we'll avoid making the distinction in the next rev.
I wonder if it would be clearer to stick to observed behaviour, rather than
motivation? So, rather than talking about a "simply malicious" or
"conspiring" log, say instead something like, "a log which does not
faithfully report all submitted entries, and/or presents different views of
the log to different observers".
the text above seems like a good way to characterize bad log behavior.
we will still include comments about motivation (that's a common aspect
of a threat model), but I agree that externally observed behavior is the
best
way to characterize this.
Note that a malicious log also could create and report entries for
bogus certificates that have not been issued by the indicated CA.
These could cause the Monitor to report non-existent semantic
problems to the Subject who would in turn report them to the
(apparently) issuing CA. This might cause the CA to do needless
investigative work or perhaps incorrectly revoke and re-issue the
Subject's certificate.
How is a malicious log going to be able to report bogus certificates? The
closest a malicious log could come is to whack together a cert chain that
has the same issuer names, etc, but that won't validate to the CA's *actual*
root certificate. Is the point of this section, then, to indicate that
reporters of bogus certificates (or the CAs that receive them) should
validate the cert chain before taking action?
good point. There has been some ambiguity about whether every log will
always
verify complete cert chains to one of the roots it accepts, in part of the
question of what level of cert path processing one can expect of a log.
If we're clear
that (good) logs will do this, always, then creating a bogus log entry
for a cert
will mark a log as misbehaving. In that case, checking the cert chain for a
log entry will detect such misbehavior. We'll add text to this end. Thanks.
>From Note 5:
Absent a ''gossip'' mechanism that enables Monitors to verify that
data from logs are reported in a consistent fashion, CT cannot claim
to provide protection against logs that are malicious or may
conspire with, or are victims of, attackers effecting certificate
mis-issuance. Developing such a mechanism is not easy. The mechanism
SHOULD protect the privacy of users (with respect to which web sites
they visit). It needs to scale to accommodate a potentially large
number of self-monitoring Subjects and a vast number of browsers (if
browsers are part of the mechanism). Even when a gossip mechanism is
defined, it will be necessary to describe how the CT system will
deal with a mis-behaving or compromised log. For example, will there
be a mechanism to alert all TLS clients to reject SCTs issued by
such a log? Absent a description of a mitigation strategy to deal
with mis-behaving or compromised logs, CT cannot ensure detection of
mis-issuance in a wide range of scenarios.
This doesn't seem so much an issue of threat model, as it is a commentary on
the current state of CT, and I don't think it belongs in this document.
I agree that this note is not in the same style as most of the rest of the
analysis. However, I am concerned that we don't have agreement on how a
gossip
mechanism can work, while meeting legitimate privacy concerns and the larger
goals ascribed to it. So I think it's appropriate to retain this note
for now,
as a reminder of what needs to be addressed as part of the overall CT
architecture.
I have analogous comments, elsewhere in the doc, that mention the issue of
the role of browsers in CT and the problem of incremental deployment.
The same
arguments probably apply to those comments.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
