<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 19, 2019 at 2:27 PM Tom Ivar Helbekkmo <<a href="mailto:tih@hamartun.priv.no">tih@hamartun.priv.no</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">Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>> writes:<br>
<br>
> On Wednesday, 19 June 2019 12:57:39 UTC Phillip Hallam-Baker wrote:<br>
>> On Tue, Jun 18, 2019 at 9:33 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>><br>
> ...<br>
>> > But Let's Encrypt de-monetized certificate issuance, so now that<br>
>> > obstacle is moot.<br>
>> <br>
>> It has also eliminated the incentive to deploy DANE for free certs.<br>
><br>
> not for me, but i think you may be right in general.<br>
<br>
OK, I'll bite.  My impression has been that DANE is unwanted by the<br>
large makers of browsers because their owners also earn money from the<br>
CA business, and widespread use and acceptance of DANE would teach their<br>
customers that they don't necessarily have to pay for certificates to<br>
achieve what they want.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That is not what they told me.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The big selling point for Google Chrome has been delivering the Web page as fast as possible. The development team is very concerned with latency. So any proposal that requires more round trips is a non starter for them. DANE wasn't the first proposal to use the DNS for PKI. Before that, people were proposing using DNS to distribute OCSP.</div><br></div><div><div class="gmail_default" style="font-size:small">This is why I proposed a DPRIV type protocol several years before that WG got started. The only way to meet the latency requirement is to upgrade the DNS client-resolver protocol. One of the big limitations in the design/implementation of the DNS is that the query protocol effectively only allows one RR query per request and only one UDP response per request.</div></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">To get the browsers on board you would need to be able to offer the TLSA records with reduced latency. That is not that difficult. While it is important that DNS client-resolver queries be one packet (Anycast, server state) there is no problem returning ten packets per request.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But I am not addressing that problem right now because browser providers are fighting their own battles among themselves and not that interested in security. If you want to improve the situation there, you need to look at other deployment areas that are not already committed to one approach. Which is why I am focused on Web Services. I don't need a single browser provider to adopt my approach. </div><div class="gmail_default" style="font-size:small"><br></div><div> </div></div></div>