Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )

["George Barwood" <[e-mail]>]

----- Original Message ----- 
From: "Paul Vixie" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 16, 2009 4:34 PM
Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )


>> >> You cannot do that without backwards compatibility. And if you keep
>> >> backwards compatibility you are prone to downgrade attacks, ie.:
>> >
>> > Actually, you are NOT prone to downgrade attacks.
>>
>> True, if you deploy more forgery resistance techniques like n*queries
>> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID
>> won't help here. But thanks for clarification.
>
> adding more queries brings all kinds of questions of its own like which 
> one
> to use if the answers aren't all the same.  also, punishing folks who 
> don't
> upgrade by increasing their load.  (dns-0x20 does this also, but the size 
> of
> the punished population is smaller, being limited only to folks who 
> downcase
> or upcase QNAMEs in their responses, which was never prohibited or 
> required.)

There is a trade-off, better security versus more DNS packets.

The question of what to do if answers aren't all the same is addressed in my 
draft
https://datatracker.ietf.org/drafts/draft-barwood-dnsext-fr-resolver-mitigations/

> i think that any effort beyond dns-0x20 to secure against off-path 
> attackers
> is misplaced.

Can you give reasons? I can think of a few, although I don't think they are 
valid, there may be more:

(i) The actual situation ( provided ISPs use port randomization ), is not 
too bad.

Answer: as an IT manager, I would wish to install software that is as secure 
as possible, not relying on unknown third parties to operate as securely as 
possible.

(ii) The increased load on DNS servers/networks is unacceptable.

Answer: I don't believe this is true. But please state this explicitly if 
you think this is the case.

(iii) FUD : any change carries some risk.

Answer: it's true that implementing repetition in a resolver is quite 
complex. But I think it is doable.

(iv) It's better to solve the problem with BGP.

Answer: I'm afraid this is somewhat outside my knowledge, but answer is same 
as for (i).

> dns must be secured end to end, which will not only enable a
> new class of dnssec-aware applications, but obviate the need to secure dns
> hop by hop.

The case for DNSSEC, as has been observed by Nicholas Weaver on many 
occasions, is quite weak/unclear.

It is the application that must be secured end to end, and this is a 
cost/performance trade off.

Can you give an example of such a dnssec-aware application?

> --
> 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/>
>
----- Original Message ----- 
From: "Paul Vixie" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 16, 2009 4:34 PM
Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )


>> >> You cannot do that without backwards compatibility. And if you keep
>> >> backwards compatibility you are prone to downgrade attacks, ie.:
>> >
>> > Actually, you are NOT prone to downgrade attacks.
>>
>> True, if you deploy more forgery resistance techniques like n*queries
>> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID
>> won't help here. But thanks for clarification.
>
> adding more queries brings all kinds of questions of its own like which 
> one
> to use if the answers aren't all the same.  also, punishing folks who 
> don't
> upgrade by increasing their load.  (dns-0x20 does this also, but the size 
> of
> the punished population is smaller, being limited only to folks who 
> downcase
> or upcase QNAMEs in their responses, which was never prohibited or 
> required.)
>
> i think that any effort beyond dns-0x20 to secure against off-path 
> attackers
> is misplaced.  dns must be secured end to end, which will not only enable 
> a
> new class of dnssec-aware applications, but obviate the need to secure dns
> hop by hop.
>
> --
> 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/>
> 



--
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/>