<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 11:43 AM Paul Vixie <<a href="mailto:paul@redbarn.org">paul@redbarn.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 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></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That depends on whether your objective here is to deploy DANE TLSA records or solve the problems they were originally intended to address.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We have tried four separate end-to-end mail enhancement protocols over the years, PEM, MOSS, OpenPGP, S/MIME. Why should we assume that if the DANE WG couldn't deliver that nobody can?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The big problem with DANE is that they got the architecture wrong from the start. The way to get security policy to work is to consider it as a part of a comprehensive service discovery mechanism based on the SRV mechanism which you invented and Stuart Cheshire et. al. extended with the companion TXT records.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My proposal for doing this is here:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-01.html">https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-01.html</a></div><br></div><div><div class="gmail_default" style="font-size:small">You will note that almost the entire spec is constrained by the previous SRV and DNS Service discovery drafts. The only thing I introduce that is new is a BASE32 mechanism for presenting fingerprints of security policies, root certificates etc. etc. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://tools.ietf.org/html/draft-hallambaker-mesh-udf-02">https://tools.ietf.org/html/draft-hallambaker-mesh-udf-02</a><br></div><br></div><div><div class="gmail_default" style="font-size:small">This approach provides a superset of DANE capabilities without the need for any new records. It allows the security policy description to be obtained with a minimal number of round trips and the mechanism can be used for discovery of any service. Thus an authoritative DNS server can provide all the information required for service connection in a single round trip as additional RRs.</div><br></div><div><div class="gmail_default" style="font-size:small">DANE was a wasted opportunity because they started from the wrong place.</div><br></div></div></div>