<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Just to mention another small benefit: DNSSEC is necessary to prove
that a domain does not exist - TLS can not help here, as there is
not TLS connection.<br>
<br>
regards<br>
Klaus<br>
<br>
<br>
<div class="moz-cite-prefix">On 04.02.2014 08:43, Arsen STASIC
wrote:<br>
</div>
<blockquote cite="mid:20140204074313.GI4916@univie.ac.at"
type="cite">
<pre wrap="">@azet: DDoS utilizing DNSSEC is already an issue we have run into:
First attacks appeared in autumn 2012, in January 2013 ccTLD .ch was
under attack
<a class="moz-txt-link-freetext" href="https://www.switch.ch/about/news/2013/ddos.html">https://www.switch.ch/about/news/2013/ddos.html</a>
and in March 2013 spamhouse.org
<a class="moz-txt-link-freetext" href="http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho">http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho</a>
Software vendors have added RRL (Response Rate Limiting) to address
DNSSEC DDos. Since bind 9.9.4 its part of ISC's official bind release.
Red Hat took the RRL-patch and deployed it to REHL 6
(bind-9.8.2-0.17.rc1.el6). Ubuntu also ships bind with RRL since
version 9.8.4.dfsg.P1-5. And other vendors beside ISC (bind) also ship
patched versions for their nameserver software:
NSD: <a class="moz-txt-link-freetext" href="http://www.nlnetlabs.nl/projects/nsd/">http://www.nlnetlabs.nl/projects/nsd/</a>
Knot DNS: <a class="moz-txt-link-freetext" href="https://www.knot-dns.cz/">https://www.knot-dns.cz/</a>
Regarding deployment of DNSSEC-zones:
<a class="moz-txt-link-freetext" href="https://xs.powerdns.com/dnssec-nl-graph/">https://xs.powerdns.com/dnssec-nl-graph/</a>
@Julien: DNSSEC just checks the integrity of DNS. It's not more than
that. In order to check signatures an DNSSEC enabled resolver is also
needed!
Is it worth the effort? I do not know. But how could you with TLS
prevent, that someone has not changed DNS and points you somewhere else?
Who is really tracking if an certificate authority has changed in oder
to have evidence that possibly someone tries to redirect you? I have no
answers to that but DNSSEC can address it!
Everyone hat to decide on its own, if it's worth the effort. We are just
providing howtos to everyone.
-arsen
* Aaron Zauner <a class="moz-txt-link-rfc2396E" href="mailto:azet@azet.org"><azet@azet.org></a> [2014-02-03 18:02 (+0100)]:
</pre>
<blockquote type="cite">
<pre wrap="">So,.. does anybody remember this talk by DJB on DDOS via the DNSSEC
protocol: <a class="moz-txt-link-freetext" href="http://cr.yp.to/talks/2009.08.10/slides.pdf">http://cr.yp.to/talks/2009.08.10/slides.pdf</a>
I'm not that up-to-date on that, but as far as I know this issue presists,
right?
Aaron
On Mon, Feb 3, 2014 at 5:24 PM, Julien Vehent <a class="moz-txt-link-rfc2396E" href="mailto:julien@linuxwall.info"><julien@linuxwall.info></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2014-02-03 11:04, Alexander Wuerstlein wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 14-02-03 17:00, Julien Vehent <a class="moz-txt-link-rfc2396E" href="mailto:julien@linuxwall.info"><julien@linuxwall.info></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
There has been a lot of discussions on whether DNSSEC adds security when
already using TLS at the protocol level. The main argument is that both
TLS and DNSSEC use a 3rd party trust model, and thus have the same level
of security. If an attacker can obtain a certificate for example.net, he
should be capable of obtaining a signed DNS record for example.net.
The question is then: is DNSSEC worth the effort?
</pre>
</blockquote>
<pre wrap="">
That is a very HTTP-centric view of things which is only valid if there
is nothing else. But redirecting SMTP connections via faked DNS entries
is still a problem even with TLS since SMTP only uses opportunistic
encryption with minimal or no checks. Other protocols may have similar
(albeit similarly stupid) problems, so yes, DNSSEC is worth the effort,
at least until every protocol does TLS properly and always.
</pre>
</blockquote>
<pre wrap="">HTTP is irrelevant here. The same security concept applies to any protocol
that relies on TLS. What you are discussing can be broken down in 3
categories;
1. transport protocol is cleartext
2. transport protocol uses opportunistic encryption (STARTTLS)
3. transport protocol enforces TLS
I am only challenging the level of security that DNSSEC adds in category 3.
For category 1 and 2, we could argue that the need for transport level
encryption is still there, and not covered by DNSSEC. Thus, does DNSSEC
solve
a problem that is worth the (significant) effort it takes to deploy it.
Or would that time be better spent enforcing TLS on those services?
(you can tell you smtp client to require STARTTLS, btw)
- Julien
_______________________________________________
Ach mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a>
<a class="moz-txt-link-freetext" href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
Ach mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a>
<a class="moz-txt-link-freetext" href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ach mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a>
<a class="moz-txt-link-freetext" href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a>
</pre>
</blockquote>
<br>
</body>
</html>