Subject: [Trans] Review of draft 03 of the threat analysis document

From: Eran Messeri <[email-masked]>
Date: Thu, 24 Dec 2015 16:38:45 +0200

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.

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.

- 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/#!search/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).

- 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.

- 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.

Cheers,
Eran

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Dec 2015 16:26:14 -0500

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.
> (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.

> 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