<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 11:41 AM, Jacques Latour <span dir="ltr"><<a href="mailto:jacques.latour@cira.ca" target="_blank">jacques.latour@cira.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> DS records now withdrawn and domain working again.<br>
<br>
</span>:-( how about fixing DNSSEC instead?<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">​To do that, you have to understand what it is for. Which folk refuse to consider.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The big problem of DNSSEC is that there is only one type of information that is worth securing with it that can be secured with it - security policy. And DANE is broken for reasons its perpetrators were aware of but chose to ignore. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first step is to define the service resolution mechanism. IETF has done this with the extended SRV + TXT record scheme but the people who did that work were being hounded by purists who didn't understand the issues so we have a framework in which each application can roll their own security policy rather than an actual mechanism.</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">So imagine your DNS has records like </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">$origin <a href="http://example.com">example.com</a>.</div><div class="gmail_default" style="font-size:small">_http._tcp  SRV ..blah</div><div class="gmail_default" style="font-size:small">_http._tcp  TXT "tls=require/1.3 pkix="MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ"<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Which means connect using a minimum of TLS 1.3 and a cert that matches or validates under a cert matching this fingerprint.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">OK so now you can stop a downgrade attack using a validating resolver and the DNS resolution protocol. But the problem is that the attacker can still perform a downgrade attack and so can an incompetent sysadmin. And there are enough of those for DNS resolvers to start turning off validation if too much fails..  :(</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">This issue led me to the realization that the DNS resolver should do the full recursive discovery and cache information for future use so that if signatures don't validate, you can back up to a previous security policy which was likely OK.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Of course once your DNS resolver is this intelligent it might as well do the SRV jump for you and hand you back the TLS cert of the service. That allows you to begin the initial handshake encrypted.</div></div></div></div>