[messaging] yet another CT thread

[Tao Effect]

Dear Joe & elijah (or Elijah?),

On Oct 3, 2014, at 12:54 PM, elijah <elijah at riseup.net> wrote:
>> In the CT world, auditing and monitoring are two very different things,
>> and they must not be confused.
>> 
>> Auditing does not detect mis-issued certificates/keys/whatever before
>> the fact, during the fact, or after the fact [1].
> 
> Hmmm... I am not even talking about CT, but the general class of
> approaches that rely on auditing (of which CT is one example).
> 
> It feels to me that you are compelled to keep bringing up this point
> about CT, even in reply to tangentially related posts, because you have
> not received any sense that others understand your critique.

Well, I have received the sense that some have understood the critique. It's just that I see what appear to be false/inaccurate understandings of CT being spread around and that's when I feel the urge to speak up. Isn't it important that everyone who is discussing and making decisions about CT have an accurate understanding of it?

> Your scenario, afaik, is an attacker who can mitm any and all network
> connections and so can inject bad data in the gossip among monitors and
> the connections between user-agents-auditors and monitors. To me, this
> assumes that this global mitm attack has existed for all time, since
> once a user agent or a monitor is able to initially bootstrap some
> correctly authenticated secure connection with a monitor, they should be
> able to detect subsequent mitm attempts from that point forward.

It does not assume a global MITM, but a global MITM is possible. It certainly is not discussing MITMs who are performing attacks in perpetuity (that is impractical).

There are two attacks mentioned in that post, one of which you loosely described above here (with the exception that I'm not discussing a perpetual MITM attack).

The other is simply the traditional TLS MITM attack wherein a CA issues a fraudulent cert (the primary impetus for CT). The post was updated (search it for "September 27") to point out that CT doesn't actually guarantee detection of this basic attack.

The original attack is potentially catchable via gossip of STHs after the fact, depending on how that gossip is implemented.

The traditional attack is not. Here a copy of the update that was made to the post, where this is discussed:

###

I’m not sure how no one brought this up until recently [1], but the attack can be much simpler. None of CT’s proofs (audit or consistency proofs) will detect mis-issuance of a certificate by a rogue CA, not even if gossip of STHs (signed-tree-heads) successfully occurs [2]. On the other hand, if CT switches to using SCTs for gossip [3], that might successfully catch the CA responsible if the MITM leaves [4] and if the server software keeps track of all the certs it issued. It will not help, however, if a revoked certificate was used for MITM.

[1] http://www.ietf.org/mail-archive/web/trans/current/msg00588.html
[2] https://moderncrypto.org/mail-archive/messaging/2014/000873.html
[3] http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf
[4] http://www.ietf.org/mail-archive/web/trans/current/msg00600.html

###

Back to your questions:

> (1) do you agree that once correctly authenticated connections are
> established with monitors that future mitm will be prevented (connection
> will fail close, system will refuse to work)?

I'm not sure what you mean by "future mitm" (could you elaborate? is this referring to before-the-fact? for the same website? same MITM?).

So I'll give you a "tentative yes" (depending on your answers) so long as these conditions are met:

1. The Monitor is trustworthy (doesn't lie).
2. The Monitor monitors *all* possible logs.
3. This system is feasible in reality (quite a lot to ask of the Monitor).

> (2) if not, do you agree that CT could be modified to perform in this manner?


In the post and in the quote from it above I showed how gossip can be done in a way that catches the MITM (by gossiping certs between clients/servers). Note that this mechanism can be done today without needing to rely on Monitors, Auditors, Merkle Trees, or any of the rest of the CT system.

Now, to answer Joe:

On Oct 3, 2014, at 2:03 PM, Joseph Bonneau <jbonneau at gmail.com> wrote:

> I'd add a third question: in the threat model in which CT doesn't work, does a blockchain-based approach work? Can't a permanent MITM that a user doesn't have any secure channel to avoid also confuse that user into accepting an incorrect block chain?

This question was brought up by Tony over on [metzdowd] and thoroughly dissected.

TLDR: We are not discussing permanent MITM (those break all systems), but for non-permanent MITM the blockchain provides better protection than CT for numerous reasons, including:

1. MITM cannot attack the data that has been downloaded and unlike CT there is only one log to monitor [everything prior to the fork is accurate in other words],
2. It is far easier for Alice to detect and recover from an attack, and
3. There is a very tiny window in which a meaningful attack can occur [MITM would need to anticipate the exact time of registration, a nearly impossible task, to falsify data, and beyond that it can only censor updates, not falsify them].

For the complete answer, see these emails and surrounding ones (feel free to read the whole thread if you have the free time). They are in reverse chronological order:

- http://www.metzdowd.com/pipermail/cryptography/2014-September/023035.html
- http://www.metzdowd.com/pipermail/cryptography/2014-September/023034.html
- http://www.metzdowd.com/pipermail/cryptography/2014-September/023031.html

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141003/dab9a036/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141003/dab9a036/attachment.sig>