<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 6, 2017 at 10:16 AM, Paul Hoffman <span dir="ltr"><<a href="mailto:phoffman@proper.com" target="_blank">phoffman@proper.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 Mar 2017, at 23:28, Ralf Weber wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Moin!<br>
<br>
On 5 Mar 2017, at 17:01, Phillip Hallam-Baker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are two issues, both of which I brought up at the start of DPRIV:<br>
<br>
1) Must be supported by browsers.<br>
2) Protocol MUST be entirely state free<br>
<br>
If you want a protocol to be deployed, you need to solicit input from the<br>
people who you need for deployment and take notice of it. DNS over anything<br>
TCP is not going to measure up.<br>
</blockquote>
+1. I brought up similar concerns in dprive, but the counter argument was<br>
always that people run web services with it so TCP does scale. The problem<br>
with that argument is that people don't want to invest the same money in DNS<br>
services that they are investing in HTTP services.<br>
<br>
Running a DNS over TLS for a couple of users is easy, but running it for<br>
millions of users is not easy. As these scaling issues were brushed aside<br>
in the working group we now have to face them at deployment stage or maybe<br>
we won't see widespread deployment.<br>
</blockquote>
<br></span>
They were not "brushed aside": there was a second document that used DTLS that is now RFC 8094. If you feel that it is superior for large-scale use, it would be valuable to show evidence of that so that implementors will know about it.</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Well if you had actually listened to the issues raised, you would know why DTLS is not a solution either.​</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">You are trying to gaslight me here. Stop it.</div><br></div><div class="gmail_default" style="font-size:small">​The large public resolvers all use anycast for performance. They also use stateless load balancing inside their infrastructure.​ I know what DTLS would do for our system and the issues at Google etc. must be orders of magnitude worse.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yet again a DNS area group proposing a security feature ignored the deployment issues raised by the deployment stakeholders. Then when their proposal is ignored they complain about the stakeholders not taking the security problem seriously rather than their refusal to meet their needs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">DNSSEC was all ready to roll out in .com back in 2001 with the ATLAS upgrade. The only reason it did not deploy was intransigence from the DNS area.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">DANE could have been a valuable contribution had the architecture separated the certificate publication and security policy enforcement functions. You refused and the proposal is worse than dead.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">DPRIVE follows in a long list of failed projects.</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">At some time Paul, you might just realize that the ability to ram a specification through IETF at the fastest possible speed is not the best way to achieve deployment in the real world.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Getting fast IETF process has never been my primary objective. In fact I have deliberately slowed some proposals because I needed to get some stakeholder on board.</div></div></div></div>