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

[Phillip Hallam-Baker]

On Fri, Jun 25, 2021 at 9:04 PM Ray Dillinger <bear at sonic.net> wrote:

>
>
>      I will share a tale of woe that I seldom tell because it is
> embarrassing.  However it is relevant.
>

It is a mistake to draw conclusions from single observations. There are
several fundamental problems here:

1) DNS is a fundamentally shitty network protocol. It costs hundreds of
millions of dollars a year to run core DNS. The responses returned are
frequently stale. Above all, the protocol makes no attempt to respect the
uses that are made of DNS (split horizon etc.) and the operations community
treat the original design as holy writ chiseled in tablets of stone.

2) In particular, 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.

3) There is a valid role for filtering DNS for the purpose of protecting
the relying party. That does not mean that we have to design systems so
that every party can demand filtering. 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.

4) Attempts to revise the DNS system have invariably fallen foul of second
system syndrome. DNSSEC it a half baked attempt to turn the DNS into a PKI
that has since been adopted as a solution to DNS insecurity despite the
fact that nobody can use DNSSEC errors to reject responses because it is
far more likely these are due to misconfiguration than an attack. Meanwhile
the resident NSA shill successfully turned DPRIV and DANE into protocols
that would block deployment of any competent effort in that area.


OK so what should DNS resolution look like? Well this is what I plan to
implement on the Mesh.

First note that the Mesh Reliable UDP Datagram (RUN) protocol is designed
to support transaction and telemetry services over UDP. It is essentially
QUIC for those specific uses rather than being optimised for HTTP traffic.

RUD allows a device connected to a Mesh profile to establish a mutually
authenticated, secure connection with another RUD peer that provides TCP
and TLS like properties but with zero maintenance. So if the client isn't
using a RUS service, there is no UDP traffic to the RUS service host. A
connection can be dormant for hours, months, years. The protocol does not
impose any rekeying assumption (but policy might). If rekeying is
performed, it is ratcheted so that the new key depends on the old plus the
refreshed parameters.

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.


Omnibroker queries can be straight DNS, OCSP or Callsign lookups. There is
no need to have separate protocols for every lookup under the sun. A
resolver that caches DNS can cache OCSP tokens as well.

Queries can also be for a set of information relevant to a discovery
operation. So "What do I need to know to create a HTTP session to
example.com' and back comes the security policy (TLS/1.2 always offered,
here is the IP address of the first host to try, here is its server cert,
here is its OCSP token)

Omnibroker resolution can be trusted or untrusted or both. Consider the
case where my coffee grinder makes an Omnibroker request so it can place an
order for beans. Do I really want to have that device performing path math?
Probably not. Do I want to trust my omnibroker provider absolutely, maybe
not. For this implementation, coffee pot connects to a local TRUSTED
omnibroker relay and just receives the answer to the question. The relay
connects to some omnibroker service provider which does the caching job
etc. and returns the full proof chain for its answer. The relay can then
verify the proof chain before or after the redacted response is returned
according to the degree of trust.

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

Filtering out bad sites using a blocklist is something I plan as a PREMIUM
feature. Its just another approach to anti-malware. Sure, Anti-virus cuts
down on the amount of software you can run. People still pay for it.


Omnibroker has two functions. First it cleans up the existing mess so that
there is a simple, efficient means of using the existing discovery system.
Secondly, it allows transition to use of callsigns.

If a site holds the callsign @service, omnibroker services (and Mesh
conformant DNS resolvers) will direct all DNS queries to the zone
service.mesh to an authoritative DNS service whose IP addresses are
published through the Callsign registry.

This architecture was originally developed in response to a request to
propose a discovery system that cannot be blocked by government censors in
Iran, Cuba, Syria, Russia, etc. It provides an absolute minimum surface
area for traffic analysis.


I haven't re-implemented RUD on top of the Mesh yet but I plan to do this
soon. Further research is necessary to add features like onion routing to
RUD and to make use of IPv6 link local private addresses and to support
seamless transition across network boundaries. If someone moves out of
their home to the office, they will move from one private network behind a
NAT, to a public Internet (cellular) to another private network behind a
NAT with a different public IP address. RUD sessions should persist
irregardless and DNS queries should also work properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210626/67ca7df7/attachment.htm>