<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 30, 2021 at 1:28 AM Viktor Dukhovni <<a href="mailto:cryptography@dukhovni.org">cryptography@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 28 Jun 2021, at 2:37 pm, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br>
> <br>
> 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.<br>
<br>
Latency has nothing to do with it.  They wait for A/AAAA lookups to complete, and<br>
the TLSA lookup can be done in parallel with the A/AAAA lookup, and even overlap<br>
the connection establishment.  The TLSA RRs are only needed at the point at which<br>
the server certificate chain is being validated.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">So the Google engineers I had extensive discussions with before DANE and DPRIV began were lying and the statements they made were false.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, the lookups can be done in parallel. So it is only one round trip. But the browser still has to wait for the second lookup to complete and at the time, the Chrome team's bonuses were tied to latency and they had no inclination to try to persuade management to change that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Chrome is written in C++ which doesn't support the type of await features that would allow that type of synchronization to be done seamlessly.</div><br></div><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">
There is however a real obstacle, which is that various captive portals, and shitty<br>
ISP-provided CPEs get in the way of end-to-end DNSSEC.  This does mean that the<br>
user's stub resolver needs a way to bypass the local network, just as it would<br>
for your non-DNS protocol.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That is also an obstacle. But the rather larger one is that DNS registrars don't actually make money selling DNS names, that is merely the loss leader for their Web hosting products. And a major part of that business is upselling customers to TLS certificates.</div></div><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">
Basically, the obstacle is that edge-network providers mediate DNS resolution.<br>
There are both good and bad reasons for them to do that.  The real world is full<br>
of messy trade-offs. :-(<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">The obstacle in DANE and DPRIV was that the group were persuaded to ignore the requirements stated by the parties they needed for deployment.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't go to IETF to develop specifications. If I want to write a spec, I find five or six people with some serious expertise and discuss it with them. The only reason to take a spec to a standards org is to get buy in from a wider constituency, to discover requirements and constraints that had not been anticipated and fix them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At the DPRIV kick off we were told that whatever scheme the group chose had to be implemented within a year 'or it would fail; So the only implementation possible was DNS over TLS. So we should use TCP Quickstart to overcome the latency issue. So to get the protocol widely adopted we 'must' use a feature that isn't supported in Windows or macOS or iOS or Android because designing a simple UDP key exchange tied to a DNS published key would take too long! That was in 2014.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now we can argue if this was merely stupidity or deliberate sabotage. But I find it really hard to believe that both efforts to increase Internet security were derailed in the same way and by the same individual.</div></div></div>