[Cryptography] Doing DNS properly Re: Apple's iCloud+ "VPN"

[Bill Woodcock]

> On Jun 26, 2021, at 8:17 PM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:
> The operations community treat the original design as holy writ chiseled in tablets of stone.

I don’t think that’s a reasonable criticism.  First, we’re the ones who have to spend the hundreds of millions of dollars, and a huge portion of that goes to supporting all of the new and unproven parts of the camel.  The people conjuring up the new parts of the camel don’t contribute to paying for the mess they create.  Second, it is exactly us, the operations community, who have been hammering on people for two and a half decades, now, to follow our lead in implementing DNSSEC, for instance.  It is we who are pushing for DoT, and now ADoT.  It is we who are pushing for DANE.  The _vast majority_ of the new innovations in the DNS never get used.  I know, I’ve paid for implementing countless numbers of them, only to see them never gain traction.  It doesn’t mean that I’m going to stop paying for innovation, but it also tempers my expectations when I see yet another kid reinventing yet another service discovery mechanism because they can’t be troubled to read RFCs from before they knew what the Internet was.  Or reinventing tunneling yet again, on top of HTTPS, which they believe to be the physical layer of the network.  And is so convenient because it already provides all the unambiguous identification of users necessary to ensure profitability in the surveillance economy.

So, no, that’s not a reasonable criticism.  It is not borne out by the facts, and any alternative would be qualitatively worse.

> The default assumption in DNS is that you obtain service from the party providing your network connection and even if you override this default, the traffic between your machines and the resolver is en-clair and unauthenticated.

Right, an assumption that the operations community has been working diligently to overturn for more than fifteen years.

> There is a valid role for filtering DNS for the purpose of protecting the relying party.

Yes.

> That does not mean that we have to design systems so that every party can demand filtering.

Yes.

> If I have a nuclear power plant, I do not want the control systems seeing more than a very very small fraction of the Internet. In my house I have absolutely no interest in allowing machines to resolve any domains in TLDs run by the Russian mafia. The fact that someone puts a host on the net does not oblige me to allow it to talk to my systems.

Yes.  I very much agree with each of the above points.

> Attempts to revise the DNS system have invariably fallen foul of second system syndrome. DNSSEC is a half baked attempt to turn the DNS into a PKI that has since been adopted as a solution to DNS insecurity

There’s a lot wrapped up in there, but I generally agree.  DNSSEC is over-complicated and over-fragile, too arcane, and needlessly reinvents the wheel.  Yet it is better than nothing, and it’s what we wound up with.  Notably, I’m not an apologist with respect to RPKI, so I don’t just roll over and accept whatever half-assed thing makes it through the standardization compromise process.  I do very much think DNSSEC is better than nothing, and have put my money where my mouth is for more than twenty years.

> fact that nobody can use DNSSEC errors to reject responses because it is far more likely these are due to misconfiguration than an attack.

This is absolutely incorrect.  It was the accepted wisdom until I turned validation on on Quad9.  Now all major resolvers have followed suit and enabled validation, and none of us are getting any measurable level of complaint.

> Meanwhile the resident NSA shill successfully turned DPRIV and DANE into protocols that would block deployment of any competent effort in that area.

I’ve quite liked DANE for a long time, and I’m not aware of any better solutions for many of the problems that I actually have…  Please educate me off-list, if you have time.

> So a Mesh connected device can make use of any RUD Ombibroker service. To perform a DNS lookup, the client makes a RUD request of one or more packets to a host and one or more packets are returned. Because of the aggressive crypto I am using, once a connection is established every single bit of every single packet is encrypted except for the connection ID where use of one time IDs is optional.

Let me know when you’ve got production-ready code.

> Omnibroker queries can be straight DNS, OCSP or Callsign lookups. There is no need to have separate protocols for every lookup under the sun.

Are you requiring that the client distinguish which type of label they’re querying for, or can they just supply a query string, and receive responses of whichever types exist?

> Get the foundation right and building this sort of thing only takes a few weeks.

…and convincing people to deploy it globally takes the rest of your life.  :-)

> Filtering out bad sites using a blocklist is something I plan as a PREMIUM feature.

“Premium feature?”  Are you trying to define a standard, or are you just building another cloud-centralization-libertarian-techbro thing?

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210628/bfc4df79/attachment.sig>