Re: OFFTOPIC: DNSSEC groupthink versus improving DNS

[Brian Dickson <[e-mail]>]

Duane wrote:
> Mark Andrews wrote:
>
>   
>> 	Except it wouldn't solve NXDOMAIN re-writing and other
>> 	on-path attacks which modify the returned data such that
>> 	it is believed.
>>     
>
> Others have pointed out other cases where DNSSEC won't either. Reducing
> the caching time only requires changes at the resolver end, unlike
> DNSSEC which if Bert's list is accurate is quite long and involved code
> wise.
>
>   

I don't recall any specific cases being pointed out.

If you wouldn't mind, could you give some kind of reference (e.g. who, 
or what case, or ideally, a URL pointing into the archives)?

To clarify - what DNSSEC does (or at least claims to do) is make it 
possible to validate answers to queries, against a chain of trust to 
some trust anchor.

This means one of three results occurs - a valid answer is confirmed, an 
unverified answer exists due to lack of signature (where the lack of 
signature itself is able to be validated), or tampering occurs and is 
detected.

So, it won't *prevent* tampering, but does make the data itself 
tamper-evident.

Tampering is only slightly worse than a blind DoS attack, and has the 
same results in a DNSSEC-protected world. The only incremental benefit 
of hop-by-hop crypto security would be to  make the data opaque, which 
while in theory seems better, in practice is irrelevant. If you can't 
tamper with the data, it doesn't matter whether you can see it. And 
hop-by-hop data encryption is a bigger cost than validation via 
signatures, particularly in the increase in state, and in the asymmetric 
cost model. Signatures scale very well, especially in an one-to-many 
world, which DNS is.

>> > Only if the ISP's don't supply clean path.  DNSSEC allows you to
>> > detect when the path has been compromised.
>>     
>
> Only if you already know DNSSEC mechanisms exist and they haven't been
> filtered.
>   

??

You can't filter DNSSEC mechanisms without that filtration being 
detected (on a validating resolver).

This includes the ability to determine whether DNSSEC mechanisms exist.

(The above is predicated on some configured trust anchor, either a 
signed root or via locally configured trust anchors, or DLV.)

If you believe these aren't correct statements, I encourage you to 
provide something more than a mere assertion, e.g. example, reference, 
proof, counter-example, or anything else that you think will support 
your position.

BTW - critical analysis of DNSSEC and alternatives is by no means 
discouraged, and I think any time anyone brings fresh eyes to the 
problem, only good things can come of it - if polite, reasoned discourse 
is the result.

Brian

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>