trevp at trevp.net
Fri Aug 22 17:27:48 PDT 2014
On Fri, Aug 22, 2014 at 4:29 PM, Tao Effect <contact at taoeffect.com> wrote:
> CT does not prevent Man-in-the-Middle (MITM) attacks. Given that the purpose
> of CT is supposedly to protect from such attacks, this is embarrassing and
Can we tone the language down, and try keep discussions technical and objective?
CT is out of scope here, but people keep drawing analogies from it, so
I'll briefly explain in the hope we can focus back on end-to-end
CT was designed around various constraints (performance, operational,
deployment) that exist in HTTPS. I've touched on some of that here:
Greg's alternative would be to replace the HTTPS namespace with
Namecoin and replace DNS servers with Namecoin lookup servers. That
would be extremely difficult due to the large installed base of HTTPS
and DNS servers, and expectations around existing URL names. CT
attempts to upgrade HTTPS security without requiring changes in
existing DNS and HTTPS servers and the existing web namespace.
CT changes the browser's certificate acceptance criteria from
"certificate from CA" to "certificate from CA plus signature from a
log promising to publish the certificate".
A bad-certificate attacker would have to compromise *both* a CA and a
log to issue an unpublished certificate. That raises the bar for
attack, particularly since there will be many fewer logs than CAs.
Also, such an attack could be detected via post-facto lookup / gossip
These protocols are not yet defined, but that's an issue the IETF is working on.
For further discussion, I encourage Greg and others to discuss CT at
the IETF "trans" and "therightkey" Working Groups, which are chartered
to discuss CT, and key management in HTTPS more generally.
More information about the Messaging