Re: [Trans] Threat model outline, attack model

[Ben Laurie <[e-mail]>]

On 27 September 2014 06:05, Tao Effect <[e-mail]> wrote:
> Dear Paul,
>
> On Sep 26, 2014, at 7:38 PM, Paul Wouters <[e-mail]> wrote:
>
> It would be even better it you would be part of the discussion here on
> the trans working group to ensure the gossip protocol is implemented
> in a way that is secure and useful to everyone, including yourself.
>
>
> That's very kind of you to invite me to the discussion, so I spent some time
> just now thinking about how to do gossip right.
>
> To start, I re-read the most recent document I have on gossip:
>
> http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf
>
> Then something occurred to me: for some reason, perhaps because of how
> complicated the details of CT are, I hadn't realized that I was wrong about
> something, that now seems obvious. In my blog post, I'd written:
>
> At its core, it introduces the concept of an append-only auditable log that
> is guaranteed to show the most recently issued SSL cert for any given domain
> (IF you’re able to ask it).

This is not a guarantee CT aims to provide, nor, as you illustrate
below, is it a particularly useful guarantee.

> That is actually not true (for Auditors).

Quite.

> So then I re-read parts of Steve's original post in this thread that I had
> skipped. Indeed, there it was in his "Notes", the same thing I just now
> realized (he really did a fantastic job):
>
> 1. If a CA submits the bogus certificate to logs, but these logs are not
> watched by a Monitor that is tracking the targeted Subject, CT will not
> mitigate a mis-issuance attack. It is not clear whether every Monitor MUST
> offer to track every Subject that requests its certificates be monitored.
> Absent such a guarantee, how do TLS clients and CAs know which set of
> Monitors will provide “sufficient” coverage. Unless these details are
> addressed, use of CT does not mitigation mis-issuance even when certificates
> are logged.

I agree that CT doesn't mitigate mis-issuance for subjects that do not
participate. On monitors and guarantees - anyone can run a monitor,
including, of course, the subjects themselves, so clearly there's no
barrier to participation for subjects who want to participate.

> For Auditors, it doesn't mitigate mis-issuance even for *the same* log.
> I.e., a rouge CA/log combo (let's just call them "Clogs" :P) is free to step
> in, create a fraudulent certificate, use it for MITM, and then restore the
> original, undetected even by Auditors that successfully gossip STHs! For the
> same log!
>
> The only ones who can stop this are Monitors, since they are able to request
> everything that's in the Clog and verify for themselves that there aren't
> any fraudulently issued certs.
>
> And this, my friends, is Game Over.
>
> I see no way that Monitors can save us here, even with successful gossip of
> STHs.
>
> To save us, Monitors would need to monitor *all* logs for *all* domains and
> somehow successfully get this information to people who are being attacked
> with a fraudulent certificate.
>
> Sorry, I tried, and in trying, I've realized that CT is more broken than I
> originally thought. I have no recommendations to give (except ones that
> you've heard already, and are likely "off topic" on this list).
>
> :-\
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>