Re: dnssec: resolver - application communication

[David Fort <david.fort@irisa.fr>]

Miek Gieben wrote:

>[I'm replying to myself here, because I could't find a good sub-thread 
>to hook this into]
>
>I think we're dealing with three issues here:
>1) DNSSEC "protects" the DNS infrastructure, or maybe "cleans up"
>   is a better word.
>
>2) end-user security
>
>3) debugging
>
>Ad 1:
>Currently (spoofing)attacks are not detected. With DNSSEC we are
>providing for a more secure DNS. Caching forwarders will purify the
>Net and filter out bad/bogus data.  With secure aware caching
>forwarders the ISPs protect their users and greatly reduce the effect
>of spoofing attacks.  I think this what DNSSEC aims to do on the Net:
>filter out bogus data.  I also believe that SERVFAIL is sufficient for
>this. I would call this "if it's bad, it's bad". 
>
>  
>
This is true if you exclude replay attacks. As things are DNSSECly valid 
while the RRSIG are valid, any attacker
can replay previously generated traffic. The fact that the TTL is not 
signed gives a bigger window for that attack.
So to be really secure(in case you have to do some key rollover), you 
need to have signature with small validity period,
which implies small ttl, which gives poor caching performances.

>If a caching forwarder does respond (ie. no SERVFAIL) you're still not
>sure of anything, but the chance you get a poisoned answer is smaller.
>
>  
>
A smart resolver should redo the query with CD=1 and return "Got that 
for what you asked
it is unsecure".
I was wondering if the caching forwarder could set a bit saying "not 
secure" and return datas anyway(assuming
you trust what your forwarder says).

>I don't believe any more that an user will disable DNSSEC if it cannot
>reach it's favorite website. Instead he/she will call support and ask
>what is the problem.  It is up to the website-owner to either not
>secure the domain, or secure and properly maintain it. If secured and
>not maintained, the effect is similar to lame delegations and such.
>  
>
The main problem here is debugging. Diagnosing a DNS problem can be hard 
when DNSSEC is always a
nightmare.

>Ad 2:
>Some applications and end-users will want to do their own validation.
>They want to be sure to talk with the right party, for instance when
>doing on-line shopping or banking, or use the DNS to exchange IPsec or
>SSH key information.
>
>For those applications, security is mandatory, or the "it's only OK,
>when it's OK" principle: if the the validation checks out, it's OK, if
>not, the info is unusable. It does not matter whether the failure to
>validate is caused by attacks, bad administration, or due to data
>which is intentionally (read: verifiable) unsecured.
>  
>
For me the resolver should always return datas even if it couldn't 
validate them, it may set
a flag to tell if the validation failed/succeed.

>Ad 3:
>David has a valid point in that you can use CD=1 and query your
>forwarder to debug. However if your forwarder is malicious this won't
>help. I believe we also need to develop debugging tools that go after
>the authoritative servers directly.
>
>grtz,
>--Miek
>
>  
>
grtz.

PS: i'm currently listing issue that a resolver could have(this is 
mostly implementation recommandations),
and will probably post it here.

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33