<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Mon, Jun 28, 2021 at 4:19 AM Bill Woodcock <<a href="mailto:woody@pch.net">woody@pch.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">
> On Jun 26, 2021, at 8:17 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br><br>
> 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<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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</div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Meanwhile the resident NSA shill successfully turned DPRIV and DANE into protocols that would block deployment of any competent effort in that area.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br>
<br>
Let me know when you’ve got production-ready code.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Have I ever kept that a secret?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Omnibroker queries can be straight DNS, OCSP or Callsign lookups. There is no need to have separate protocols for every lookup under the sun.<br>
<br>
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?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Omnibroker queries can contain</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* An encapsulated binary DNS query</div><div class="gmail_default" style="font-size:small">* An encapsulated OCSP query</div><div class="gmail_default" style="font-size:small">* A callsign lookup</div><div class="gmail_default" style="font-size:small">* A generic discovery request</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The last one allows a client to specify the domain name (<a href="http://example.com">example.com</a>) and the service name (_http._tcp). The response then contains all the information the client needs to connect to a specific host.</div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Get the foundation right and building this sort of thing only takes a few weeks.<br>
<br>
…and convincing people to deploy it globally takes the rest of your life.  :-)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Filtering out bad sites using a blocklist is something I plan as a PREMIUM feature.<br>
<br>
“Premium feature?”  Are you trying to define a standard, or are you just building another cloud-centralization-libertarian-techbro thing?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am not a libertarian techbro (whatever that is). But none of us are communists.</div><br></div><div> </div></div></div>