Eran,
Overall this is a very thorough document, I find it describes pretty
well the scenarios where CT is and isn't effective, so the work to
codify these scenarios is much appreciated.
thanks.
I'll send the editorial comments separately, the broader comments I
have are:
- I find the distinction between self-monitoring Subjects and
third-party Monitors a bit superfluous - it seems to me the implicit
trust relationship when a Subject relies on a third-party Monitor to
detect mis-issuance on its behalf which is the same for
self-monitoring Subject, which trusts its employees (for example) to
alert about mis-issuance. My proposal is to merge these two cases in
most cases and point out explicit cases where there's reliance on
out-of-bound channels (e.g. what's described in section 3.1.2.1) for
monitoring operations.
I think it is useful to treat these two separately for a few reasons. A
self-monitoring Subject has no trust issues with the entity performing the
Monitor function, unlike in the case of a third party Monitor. While I agree
that there is an implicit trust relationship in the second case, it is
important
to make this distinction explicit when discussing attack models. too
often implicit
trust assumption lead to ignoring these assumptions when evaluating
system security.
Also, if a CA elects to provide Monitor service for the Subjects to
which its issues
certs, it will be easy for these Subjects to not think about the
additional trust
they have vested in the CA. Moreover, a self-monitoring Subject may face
more problems acquiring log metadata than a third party Monitor, and if
many Subjects elect to self-monitor, the burden on CT system resources
grows, a possibly important architectural issue.
- The document correctly points out scenarios where CT would not help
detect mis-issuance, based on the assumptions that relaying parties
(browsers) do not contact logs for inclusion checking or doing
anything with the received SCTs. However, given there are plans to get
clients to report SCTs back to websites
<https://groups.google.com/a/chromium.org/forum/#%21search/expect-ct/chromium-reviews/kJmKKydQ0DU/7NNZia3fDAAJ>
it'd be useful if the threat analysis document took that into account
(to be fair an up-to-date description of the ideas for implementing
the Audit function is in order).
The gossip aspect of Auditing is only targeted as Experimental at this
time, which
is why I tended to not put much emphasis on the mechanisms being
explored in that
context. But, I could add a paragraph stating that such a mechanism
might become available in the future, and note that it would address
this problem of not having
SCTs verified via inclusion proofs. This is the text I propose to
include in the introduction, on page 5:
Also note that one proposal for distributing Audit information (to
detect misbehaving logs) calls for a browser to send SCTs it
receives to the corresponding website when visited by the browser.
If a website acquires an inclusion proof from a log for each
(unique) SCT it receives in this fashuion, this would cause a bogus
SCT to be discovered, and, presumably, trigger a revocation request.
- More broadly browsers may, while not outright rejecting certificates
without SCTs, can provide other indication to users that some
certificates are likely to be publicly known by being accompanied with
SCTs.
I agree that a browser might notify a user in some fashion about the
lack of an
SCT for a cert, short of rejecting the cert. However, what you seem to
allude to
above is a sort of external info about which sites are know to have
SCTs. This is not
metadata that has ever been mentioned in 6962-bis, so for now it strikes me
as out of scope. However, if a browser requirements doc were to specify
how this
is to be done, then I would certainly add it to this discussion.
- The description of attackers is pretty accurate. I suggest
explicitly stating (in section 2) that traffic interception with
consent of the relaying party (browser), e.g. when a user installs an
anti-virus which adds a root certificate to the local trust store, are
explicitly out of scope for Certificate Transparency and are not
considered a threat.
Good point, I'll add the following text to Section 2:
Finally, note that a browser trust store ,ay include a CA that is
intended to issue certificates to enable monitoring of encrypted
browser sessions. The inclusion of a trust anchor for such a CA is
intended to facilitate monitoring encrypted content, via an
authorized man-in-the-middle (MITM) attack. CT is not designed to
detect and counter this type of locally-authorized interception.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
