[cryptography] The Trouble with Certificate Transparency

Paul Wouters paul at cypherpunks.ca
Sun Sep 28 20:23:30 EDT 2014

On Sun, 28 Sep 2014, Nicolai wrote:

>> You took it out of context. What I wrote was about certificate checking:
>> 	Of course, one has to be careul not to make the same privacy mistakes as
>> 	CRL/OCSP did. But we have other decentralised methods that have better
>> 	privacy (such as dnssec, onion sites or whatever blockchain variation
>> 	you think is stable infrastructure)
>> This is about the privacy of sending centralised entities a request for
>> some "certificate validation" every time you visit their website by performing
>> a "certificate check". Like sending Comodo a OCSP request everytime I
>> visit https://privacy.org.
>> A better method for distributing such certificate validity information
>> is using DNS(SEC), as those queries are are cached and decentralised. No
>> single entity can track those back to me. There is no direct link
>> between my DNS query for TLSA of privacy.org versus someone else's,
>> if it is going through ISP caches, external DNS providers, etc etc.
> I understand your point and agree -- all I'm saying is that this is a
> property of DNS, not DNSSEC.

DNSSEC is still needed for the authentication property if you use it to
validate TLSA records.

> Would you agree that DNSCrypt is more of a "privacy method" than DNSSEC
> in this context, since DNSCrypt inherently decouples the client from the
> resolver, unlike DNSSEC, which can be run on localhost?

No. On the contrary, DNScrypt requires a centralised and
pre-authenticated setup. It is basically a "VPN for only DNS".
The fact that the transport layer is encrypted does not help the privacy
issue at all of having a track record of queries that show which
websites you go and which certificates you are interested in.


More information about the cryptography mailing list