<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Fri, Jun 25, 2021 at 9:04 PM Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
     I will share a tale of woe that I seldom tell because it is<br>
embarrassing.  However it is relevant.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It is a mistake to draw conclusions from single observations. There are several fundamental problems here:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">OK so what should DNS resolution look like? Well this is what I plan to implement on the Mesh.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <a href="http://example.com">example.com</a>' 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)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">Get the foundation right and building this sort of thing only takes a few weeks.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>