<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 4/25/2025 5:29 PM, Christian de
Larrinaga wrote:<br>
</div>
<blockquote type="cite" cite="mid:87msc4a1ty.fsf@firsthand.net">
<pre wrap="" class="moz-quote-pre">Shreyas Zare <a class="moz-txt-link-rfc2396E" href="mailto:shreyas@technitium.com"><shreyas@technitium.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On 4/25/2025 3:36 PM, Christian de Larrinaga wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Shreyas Zare via cryptography<a class="moz-txt-link-rfc2396E" href="mailto:cryptography@metzdowd.com"><cryptography@metzdowd.com></a> writes:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">*That* is what certificates protect against. DNSSEC will not help
you at all because as long as you are connected to my hot spot, I
control the entire Internet from your point of view, not just DNS.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">DNSSEC will help protect with DANE. Controlling a hot spot does not
make it vulnerable.
Its about time web browsers add support for DANE as an alternative
option for people who want to use it.
Regards,
*Shreyas Zare*
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">DNSSEC signing a zone to the root is needed first?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Yes, that's the prerequisite to have the zone signed. Which is much
easier to do with some DNS providers which give you an ON/OFF switch
to sign your zone.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
if DANE is totally dependent on DNSSEC being correctly implemented that
is a significant barrier.</pre>
</blockquote>
<p>These things are automated and the zone admin does not have to
manually do most of the things anymore. It does require some
learning to be done by the admins similar to how they needed to
learn to get and deploy SSL certs. Its not much different and
easily doable. Its even better once deployed since there is no
concept of "expiry" like with SSL certs and user can define how
frequent they wish to do a key rollover.<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:87msc4a1ty.fsf@firsthand.net">
<pre wrap="" class="moz-quote-pre">In regards validating self signed certs in DANE how does the service and
also a user of a service that has implemented DNSSEC and DANE for a zone
distinguish if both the DNS delegation is signed and operating correctly
and the service self signed cert is authentic and can be "trusted"?
</pre>
</blockquote>
<p>DANE uses TLSA DNS resource record which contains the hash of the
SSL cert so that the client can match it with the cert the server
returned during TLS handshake to validate it. Application that
support DANE would need to use a DNS library that does DNSSEC
validation to fetch TLSA record. If the TLSA record is returned
without any validation errors, it can be used to validate the
server's SSL cert. The library just needs to know the root zone's
public key hashes (root anchors [1]) and it would validate all
delegations using it automatically.<br>
</p>
<div class="moz-signature">
<p>
Regards,<br>
<b>Shreyas Zare</b><br>
<a href="https://technitium.com/">Technitium</a>
</p>
</div>
<p></p>
<p>[1] <a class="moz-txt-link-freetext" href="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</a><br>
</p>
</body>
</html>