Re: [Trans] Threat model outline, attack model

[Dmitry Belyavsky <[e-mail]>]

Hello Stephen,


On Mon, Sep 15, 2014 at 10:52 PM, Stephen Kent <[e-mail]> wrote:

>  Dimitry,
>
>    Stephen,
>
>  thank you for the formal description of treat model.
>
>  But I think that the Auditors should be mentioned in it too. If I am not
> mistaken, they are designed to watch the certificates with suspicious
> properties (CA permissions, etc.).
>
>  So the treats which are to be avoided using the Auditors seems to be
> missing.is case, the CT mechanisms have detected mis-issuance, but are
> not able to remedy the problem. (See Note 4 below.)
>
>
> In 6962-bis (-04) the definition of the Auditor function is:
>
>    Auditors take partial information about a log as input and verify
>
>    that this information is consistent with other partial information
>
>    they have.
>
> This is way too vague to be meaningful. So, I agree that an Auditor might
> be relevant
> to the attack analysis, I didn't include it this time because there is not
> a sufficiently
> detailed description of its functions. The examples of what an Auditor
> "can" do don't
> mention checking cert content against a set of criteria. They focus on
> detecting log
> inconsistencies. So, maybe Auditors should be mentioned in the discussion
> of detecting
> log misbehavior.
>
>
My fault. The certs with unnecessery permissions are a subject to be
Monitored, not Audited.

There is a high-level description of the Auditors here:
http://www.certificate-transparency.org/what-is-ct:
=====
Auditors are lightweight software components that typically perform two
functions. First, they can verify that logs are behaving correctly and are
cryptographically consistent. If a log is not behaving properly, then the
log will need to explain itself or risk being shut down. Second, they can
verify that a particular certificate appears in a log. This is a
particularly important auditing function because the Certificate
Transparency framework requires that all SSL certificates be registered in
a log. If a certificate has not been registered in a log, it’s a sign that
the certificate is suspect, and TLS clients may refuse to connect to sites
that have suspect certificates.
=====
It is not integrated as a part of neither RFC 6962 nor current draft, but
it provides a high-level explanation of the Auditors' role.


-- 
SY, Dmitry Belyavsky