[messaging] Namecoin

[Tao Effect]

On Aug 22, 2014, at 5:23 PM, Chris Palmer <snackypants at gmail.com> wrote:

> On Thu, Aug 21, 2014 at 11:09 AM, Tao Effect <contact at taoeffect.com> wrote:
> 
>> - CT cannot to deliver on its promise to document every certificate that is
>> issued. It makes it possible for malicious actors to issue fraudulent certs
>> and never actually log or report them. [2] [3]
>> - Certs must be purchased via yearly subscriptions, whereas with Namecoin /
>> DNSChain they are free.
>> - CT does not prevent MITM attacks, whereas DNSChain does.
>> - Whereas certificate revocation for compromised certificates is not an
>> issue in Namecoin / DNSChain, it is still an unsolved problem with CT. [4]
> 
> http://www.certificate-transparency.org/how-ct-works
> 
> """During the TLS handshake, the TLS client receives the SSL
> certificate and the certificate’s SCT. As usual, the TLS client
> validates the certificate and its signature chain. In addition, the
> TLS client validates the log’s signature on the SCT to verify that the
> SCT was issued by a valid log and that the SCT was actually issued for
> the certificate (and not some other certificate). If there are
> discrepancies, the TLS client may reject the certificate. For example,
> a TLS client would typically reject any certificate whose SCT
> timestamp is in the future."""
> 
> Thus, clients can (and should) reject any certificate not issued in public.
> 
> Just wanted to clear that up.

Please read again reference [2]: http://www.ietf.org/mail-archive/web/trans/current/msg00233.html

See point #2 in said link. Here, I will copy the relevant portion:

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 shameful.
Expanding on 2: CT takes today's PKI and divides it up into "The Server" (the NSA), "The CA" (the NSA), and "The Log Server" (the NSA). This is how MITM works, it doesn't matter if the NSA doesn't actually own those servers because they effectively do by controlling the network itself.
Clients have no way of detecting a MITM attack because the RFC gives them no such powers. If this complicated system were implemented perfectly, then most of the security rests not on the log servers, but on the "gossip protocols" that the RFC alludes to but does not describe. These protocols are supposed to be described in other documents, but as far as I'm aware they do not exist. Nor is any hint given as to their feasibility or to how the gossip channels themselves will be protected from MITM.


I think the problem is that Google left out some words in its explanation of "How CT Works":

> "During the TLS handshake, the TLS client receives the SSL certificate and the certificate’s SCT [from the NSA]"

;)

-Greg

--
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/20140822/2399a0d7/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/20140822/2399a0d7/attachment.sig>