I'm giving a talk on Weds at #ripe76 on our survey re: interest and concerns about DNS privacy. Want to make sure this isn't like DNSSEC all over again - if we build it, will operators deploy it? Or are we adding complexity that most operators would rather not have?
-
-
Replying to @ISCdotORG @jpmens
Certificate management is still hard, and will fail the same way as DNSSEC for the same reasons. qname minimisation breaks stuff and is a solution looking for a problem. The “DNS privacy” appellation is mostly a lie as long as resolvers can, and do see and log everything.
5 replies 1 retweet 3 likes -
The only thing that kinda make sense is DoH, that can leverage existing HTTP software. Even though there is no privacy improvement here contrary to popular belief, just authentication to mitigate tampering. Like what DNSSEC has been trying to do in vain.
3 replies 0 retweets 0 likes -
“DNS Privacy” tools give *more* information to resolvers. TLS tickets, and long-lived TCP connections now allow them to fingerprint individual devices even behind Tor/VPN/NAT/CGNAT.
2 replies 0 retweets 2 likes -
“Hey Sixko, sell me your logs”: “There you go!” “Hey PassiveDB, what are supposedly private host names you saw within BankOfUSA[.]com?”: “Here’s the list!”. With “DNS Privacy” tools, add “and by the way, here’s more data from a different IP but the same user”. We solved nothing.
1 reply 0 retweets 0 likes
At least from a privacy perspective. Old protocols never get fixed no matter how many RFCs are written, unless they get replaced by a brand new thing, that is *required* to access some information.
-
-
SMTP security was never fixed, even with Gmail server requiring TLS. The way email was fixed is by being superseded by Facebook/Whatsapp/Wechat.
0 replies 1 retweet 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.