111–120 of 155 posts
So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on c…
So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on c…
IPv6 will never gain universal adoption. Nobody wants their home or their datacenter machines exposed to the whole Internet all the time. NAT is a feature, not a bug.
As a cancer survivor, using the example of someone spying on your cancer.org visit as a motivation for encrypted SNI seems a bit excessive and insensitive. There are definitely more neutral ways of motivating eSNI than invoking the fear of a stranger finding out you or a loved one has cancer. Shame on Mozilla.
Apple's contrived example from when they introduced private mode in Safari was shopping for presents and not wanting the recipient to find out, but that would be even less convincing when the person you're hiding your traffic from is the person next to you in the coffee shop.
So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on c…
IPv6 will never gain universal adoption. Nobody wants their home or their datacenter machines exposed to the whole Internet all the time. NAT is a feature, not a bug.
Earlier quoted context omitted.
> So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address Say sometimes I love to visit a very private website for my personal pleasure when I'm alone at night. Without eSNI, when I type-in pornhub.com and hit enter, my buddy Bob who working for the ISP immediately knows and be very sure that I'm trying to accessing none other than pornhub…
Maybe I'm misunderstanding, but isn't the point of the GP that as IPv6 takes over, eSNI becomes practically useless since it's possible for every site to have its own IP address? If I'm connecting to an IP address that only maps to one site, then Bob is going to be able to figure out what that site is. You're right that eSNI is a nice to have (though years late) for IPv4, but I and the GP would like to know what we c…
It's a lot of extra hassle to set up dozens of IPv6 addresses when (e)sni can do the same job.
Moreover, (e)sni has an advantage over using ip mapping; events if someone is snooping on your connection and can see that you are connecting to some ip address they won't be able to determine what site that might be.
If you are simply mapping IPs, they can visit that to see what you are visiting.
As a cancer survivor, using the example of someone spying on your cancer.org visit as a motivation for encrypted SNI seems a bit excessive and insensitive. There are definitely more neutral ways of motivating eSNI than invoking the fear of a stranger finding out you or a loved one has cancer. Shame on Mozilla.
I get you, but I suppose the most obvious alternative examples are things like porn or illegal sites, which they might not have wanted to use. What alternative examples would you have preferred? Apple's contrived example from when they introduced private mode in Safari was shopping for presents and not wanting the recipient to find out, but that would be even less convincing when the person you're hiding your traffic…
Earlier quoted context omitted.
DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward. And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for…
And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ . He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use…
Also Thomas has rejected the suggestion that the parts of his post that are now hopelessly wrong should be mentioned in the FAQ he prominently links. So, that post is wrong and explicitly won't be fixed, you should not rely on the "facts" in it unless you want to get laughed at.
Your mention of Comodo suggests you're badly confused. The Symantec hierarchy is in the process of being distrusted by the Mozilla and Google root programmes, not Comodo.
As to .com, it already _is_ run very badly and we already do have to put up with that because there is no way to fix it. Don't put new things in .com unless you're comfortable with for-profit companies screwing you over whenever it suits them. DNSSEC can't make that worse, it's already terrible.
That's worth emphasising - DNSSEC cannot make you more dependent on your registry operators, because you are already entirely dependent on those registry operators anyway. If the operator could be leaned on by spooks (seems plausible) that is already true today.
I would love to understand why Firefox keep adding support for CloudFlare specific features.
Is it me or... > If they’re willing to convert all their customers to ESNI at once Why does it seem like this is over-engineering at it's finest? Not only are CDNs now part of the problem/solution space, but they are now dictating. It is now that much harder to diagnose issues when they do crop up, instead of checking ping or nslookup. Now, you've got to see if the DNS-over-HTTPS/The DNS record itself/Host/client/any…
It's even worse. To use ESNI you need DOH. To use DOH you need a resolver with a server certificates, which is kindly offered by the same cloud providers. So now all your base are belong to cloudflare.
Earlier quoted context omitted.
They can't, because that's handled at the OS level, not the application level. If a browser starts (purposefully) subverting the hosts file or not adhering to resolv addresses, then we've got a bigger problem. Think, a fat client resolving an address differently than a browser; then that's all sort of Pandora's Box.
DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes…
It's the default DNS in the network. Computers do not need to know the detail it gets encrypted past that point.