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

[Phillip Hallam-Baker]

On Mon, Jun 28, 2021 at 4:19 AM Bill Woodcock <woody at pch.net> wrote:

> > On Jun 26, 2021, at 8:17 PM, Phillip Hallam-Baker <phill at hallambaker.com>
> wrote:
>
> > 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.
>

My problem is that DNSSEC was rolled out as the solution to the Kaminsky
vulnerability in place of fixing the DNS protocol to add TSIG to every
communication. A solution that has a major deployment footprint should not
block simpler solutions that could have served everyone

> 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.
>

DANE killed my proposal to do general security policy through the DNS
co-authored with a Google employee who works on Chrome. So you really were
had. In place of a scheme that would have been adopted in 2011, you have a
scheme that none of the browsers implemented and none ever will.


> > 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.
>

Have I ever kept that a secret?

A group of us are proposing QUIC-like but not-QUIC schemes. It is pretty
clear they won't all make it but at least one will and Omnibroker will run
over that.



> > 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?
>

Omnibroker queries can contain

* An encapsulated binary DNS query
* An encapsulated OCSP query
* A callsign lookup
* A generic discovery request

The last one allows a client to specify the domain name (example.com) and
the service name (_http._tcp). The response then contains all the
information the client needs to connect to a specific host.

So if there is a TSLA record in the cache, that is applied, if there are
SRV records they are applied, if there are prefixed DNS discovery TXT
records, they are applied, etc. etc. The effect is similar to DNS
additional RRs but not limited to DNS data, not limited to one UDP packet
response and with a consistent semantic model applied across services. The
notion that the designers of an application should describe how to use DNS
for discovery is broken. DNS should have done that. But they kept inventing
new RRs that would never work and so the market ignored them.

Using DANE via DNS resolution is never gonna happen. It is silly to think
it could. There is no way that google is going to delay connecting to a
page while it waits for TLSA round trips to complete.

The idea of omnibroker is to mask traffic by pooling resolution across a
large number of users and to prefetch records before they are requested. So
an omnibroker resolver should be answering queries from cache almost all
the time. If there is a relevant TLSA record, that is known and will be
returned, same for prefixed TXT.



> > 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.
> :-)
>

The devil is in the deployment. But the mistake most IETF folk make is to
think that if they reduce the feature set of their proposal and thus the
value of the proposal to the absolute bare minimum, more people will be
interested rather than fewer.



> > 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?
>

I pretty much have to stand up some sort of public service if anyone is
going to use it. And my experience is that when I have started a business
area, most people copy my business model.

I am not a libertarian techbro (whatever that is). But none of us are
communists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210628/623f255d/attachment.htm>