Subject: [DNSOP] dns data exchanged between host and local dns-sever

From: "马迪" <[email-masked]>
Date: Thu, 23 Apr 2009 18:32:38 +0800

Hi, folks.
 
As we all know, DNSSEC provides origin authentication and integrity assurance services for DNS data exchanged between DNS resolver and name-sever, while DNSSEC fails to give a means by which the DNS queries or responses transmitted between a host and a recursive server could be guaranteed integrity and authentication. For example, a malicious attacker might hijack the DNS query form a host and fake a response which will help he commit phishing. So I wonder, is there someone having a certain solution, more exactly a software implementation on host, to protect against such attack?

2009-04-23 

[email-masked]

---

From: John Schnizlein <[email-masked]>
Date: Thu, 23 Apr 2009 06:47:59 -0400

RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)

This protocol allows for transaction level authentication using shared  
secrets and one way hashing. It can be used to authenticate dynamic  
updates as coming from an approved client, or to authenticate  
responses as coming from an approved recursive name server.

or

RFC 3645  - Generic Security Service Algorithm for Secret Key  
Transaction Authentication for DNS (GSS-TSIG)

The Secret Key Transaction Authentication for DNS (TSIG) protocol  
provides transaction level authentication for DNS. TSIG is extensible  
through the definition of new algorithms. This document specifies an  
algorithm based on the Generic Security Service Application Program  
Interface (GSS-API) (RFC2743). This document updates RFC 2845.

On 2009Apr23, at 6:32 AM, 马迪 wrote:

> Hi, folks.
>
> As we all know, DNSSEC provides origin authentication and integrity  
> assurance services for DNS data exchanged between DNS resolver and  
> name-sever, while DNSSEC fails to give a means by which the DNS  
> queries or responses transmitted between a host and a recursive  
> server could be guaranteed integrity and authentication. For  
> example, a malicious attacker might hijack the DNS query form a host  
> and fake a response which will help he commit phishing. So I wonder,  
> is there someone having a certain solution, more exactly a software  
> implementation on host, to protect against such attack?
>
> 2009-04-23
> [email-masked]

---

From: Scott Rose <[email-masked]>
Date: Thu, 23 Apr 2009 07:10:13 -0400

Those are the DNS protocol mechanisms in place.  There is also lower
level security technologies such as IPsec that could be used between
stub clients and recursive servers that don't rely on DNSSEC at all.

It depends on the network the client and recursive server are on.

Scott

John Schnizlein wrote:
> updates as coming from an approved client, or to authenticate responses
> as coming from an approved recursive name server.
> 
> or
> 
> On 2009Apr23, at 6:32 AM, ÂíµÏ wrote:
> 
>> Hi, folks.
>>
>> queries or responses transmitted between a host and a recursive server
>> could be guaranteed integrity and authentication. For example, a
>> malicious attacker might hijack the DNS query form a host and fake a
>> response which will help he commit phishing. So I wonder, is there
>> someone having a certain solution, more exactly a software
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Apr 2009 13:40:12 +0200

On Thu, Apr 23, 2009 at 07:10:13AM -0400,
 Scott Rose <[email-masked]> wrote 

> stub clients and recursive servers that don't rely on DNSSEC at all.

TSIG, IPsec and friends have all the same issue: they check that the
response does come from the intended resolver, not that the response
is authentic. At a time where any hotel provides Internet access with
a lying resolver, this is probably not sufficient.

---

From: Scott Rose <[email-masked]>
Date: Thu, 23 Apr 2009 07:51:45 -0400

True, which is why it depends on what the local network.   If the
clients and recursive server are all part of the same organization,
there may already be sufficient network security mechanisms in place
that additional message authentication techniques (like TSIG) will not
add any new value.

Scott

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Apr 2009 11:27:54 -0400 (EDT)

On Thu, 23 Apr 2009, 马迪 wrote:

> As we all know, DNSSEC provides origin authentication and integrity assurance services for DNS
> data exchanged between DNS resolver and name-sever, while DNSSEC fails to give a means by
> which the DNS queries or responses transmitted between a host and a recursive server could be
> guaranteed integrity and authentication. For example, a malicious attacker might hijack the
> DNS query form a host and fake a response which will help he commit phishing. So I wonder, is
> there someone having a certain solution, more exactly a software implementation on host, to
> protect against such attack?

Aside from earlier comments made, I wanted to point out the difference in scale here.

Poisoning an ISP's caching resolver is much more useful to phishing then poisoning
my laptop's DNS packet to its hotspot resolver. For untargetted massive phising attacks,
the last mile is really uninteresting. Of course, when it comes to industrial espionage
or targetting CEO's or individuals specifically, the last mile attack might be worth it,
though it's easier to send them spam emails to click on dancing bears. Of course, those
individuals SHOULD be using IPsec when using untrusted networks for many reasons, one
of which is to protect their DNS traffic.

Paul

---

From: "马迪" <[email-masked]>
Date: Fri, 24 Apr 2009 10:35:55 +0800

The information you provided  to me really helps me a lot,thank you.

2009-04-24 

马迪 

发件人： John Schnizlein 
发送时间： 2009-04-23  18:48:04 
收件人： 马迪 
抄送： dnsop 
主题： Re: [DNSOP] dns data exchanged between host and local dns-sever 

or

---

From: Holger Zuleger <[email-masked]>
Date: Fri, 24 Apr 2009 09:54:00 +0200

> responses as coming from an approved recursive name server.
Does anybody know if this is implemented by an stub resolver? As far as
I know TSIG is currently used only for DDNS (Host to ANS or DHCP server
to ANS) or to authenticate queries between name servers (ANS or RNS).
> Interface (GSS-API) (RFC2743). This document updates RFC 2845.
Same as above. I guess that this is implemented only for dynamic updates
not to authenticate responses coming from a recursive name server.

Even BIND as a (local) forwarding name server is not able to use
GSS-TSIG to protect the communication with the recursive name server.
Please correct me if I'm wrong.
I'm looking for a TSIG aware stub-resolver for years.

 Holger

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Apr 2009 11:31:24 -0500

On Apr 25, 2009, at 5:56 AM, Holger Zuleger wrote:
>> Neither my Linux install nor my Mac OS X install supports TSIG  
>> resolver queries out of the box.   Probably because you'd have to  
>> put the key in a publicly-readable file.
> I worry that it's more complicated than that.
> Plain HMAC-MD5 will not be a scalable solution. GSS-TSIG could help  
> here. But this has some other drawbacks, e.g. as a third party  
> authentication system, the client has to find the KDC first, and  
> will mostly use DNS for that. So at the end we run into a chicken  
> and egg problem.
> But maybe I have overlooked something.

I think it's important to consider what's good enough.   Right now,  
for instance, we all use ssh professionally to get work done.   How  
many of us arrange to get the host key out of band?   Probably close  
to none.   How often do we get hosed by MiTM attacks because of  
this?   It probably happens, but I haven't seen any evidence of it.    
Why?   Because the frequency of these events is so low.   The MiTM has  
to get the host key the *first time* you connect to a new host.   So  
maybe once every few years, for any given host.   It's not a very  
inviting target other than in cases of directed attacks, e.g.  
corporate espionage.

While this ad-hoc key distribution mechanism isn't foolproof, it's  
difficult to imagine how an off-path attacker could crack it.   I  
think something similar could be done for DNS resolvers with SIG(0).    
Would it be completely secure?   No.   Would it be more secure than  
what we have now?   Possibly.   My main concern would be that an  
automated mechanism could be easily convinced to cache bad keys; any  
proposal that worked this way would have to be designed to avoid that  
pitfall.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Apr 2009 13:46:08 -0400 (EDT)

On Sat, 25 Apr 2009, Ted Lemon wrote:

> I think it's important to consider what's good enough.   Right now, for 
> instance, we all use ssh professionally to get work done.   How many of us 
> arrange to get the host key out of band?

You're not using RFC 4255 yet? Shame on you!

It's not that difficult, just use:

sshfp -a -s -d  xelerance.com  @ns0.xelerance.net  >>  /var/named/xelerance.com

and re-sign your zone

And then you might need to enable VerifyHostKeyDNS in your ssh client options
if it is not enabled in /etc/ssh/ssh_config

Paul

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Apr 2009 13:13:37 -0500

From the RFC:

> Another dependency is on the implementation of DNSSEC itself. As  
> stated in Section 2.4, we mandate the use of secure methods for  
> lookup and that SSHFP RRs are authenticated by trusted SIG RRs.

So without DNSSEC, sshfp doesn't really add any security: if someone  
has control over your path, they can spoof both the SSHFP RRs and the  
host key, and in fact now you have even worse security, because ssh  
may no longer warn you that you are being given a new key.   Of course  
hopefully ssh is implemented in such a way that it makes sure the  
SSHFP RR has been validated by the resolver before using it; I haven't  
actually tried it, so I don't know.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Apr 2009 09:44:47 +0200

On Sun, Apr 26, 2009 at 01:13:37PM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 22 lines which said:

> Of course hopefully ssh is implemented in such a way that it makes
> sure the SSHFP RR has been validated by the resolver before using
> it; I haven't actually tried it, so I don't know.

At least OpenSSH appears to not do that systematically, probably
because there is no secure name resolution API, no standard way to
check the AD bit from an application (and the app will still not know
if the validating resolver was "secure", or if it was using random
trust anchors without checking).

There is an option in OpenSSH to activate DNSSEC testing for SSHFP
(see dns.c and openbsd-compat/getrrsetbyname.c) but it seems to depend
on the local stub resolver support and therefore does not work for
each system.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 27 Apr 2009 13:44:27 -0700

>>>>> On Mon, 27 Apr 2009 09:44:47 +0200, Stephane Bortzmeyer <[email-masked]> said:

SB> At least OpenSSH appears to not do that systematically, probably
SB> because there is no secure name resolution API, no standard way to
SB> check the AD bit from an application (and the app will still not know
SB> if the validating resolver was "secure", or if it was using random
SB> trust anchors without checking).

You can the patch for OpenSSH available from
http://www.dnssec-tools.org/ which does in-application validation and
ssh fingerprint accepting.  I demonstrated it's use like at a recent
NANOG, in fact.  The patch makes use of an in-application validation
library that does let the application know if the fingerprint lookup was
secure or not.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Phil Regnauld <[email-masked]>
Date: Mon, 27 Apr 2009 22:53:53 +0200

> GSS-TSIG to protect the communication with the recursive name server.

	You can setup TSIG between recursive nameservers.

> I'm looking for a TSIG aware stub-resolver for years.

	Well, Unbound does provide the necessary pieces to build one,
	but I've yet to see the OS stub resolver implement TSIG.

	Phil

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Apr 2009 11:53:05 -0400 (EDT)

On Sun, 26 Apr 2009, Ted Lemon wrote:

>> Another dependency is on the implementation of DNSSEC itself. As stated in 
>> Section 2.4, we mandate the use of secure methods for lookup and that SSHFP 
>> RRs are authenticated by trusted SIG RRs.
>
>
> So without DNSSEC, sshfp doesn't really add any security: if someone has 
> control over your path, they can spoof both the SSHFP RRs and the host key, 
> and in fact now you have even worse security, because ssh may no longer warn 
> you that you are being given a new key.

It *still* warns you about new keys and asks you to confirm it. It will just
present additional information on whether or not it matches the DNS record. It
does not replace the leap-of-faith, it adds to it.

So, there is no reason not to use it, even without dnssec. Also, if you run your
own validator, you might have cached the sshfp record before entering the
rogue network, so they won't be able to spood the SSHFP record.

Paul

---

From: "madi" <[email-masked]>
Date: Thu, 30 Apr 2009 14:15:48 +0800

Hi, Stephane.
I cannot agree with you any more. However, with regard to “the lying resolver” you’ve mentioned, to make it clearer, I’d like to bring in the Cache Poisoning which IPsec and TSIG cannot protect against. In practice, the response form the intended recursive server is in the form of plaintext. Once a recursive server has been hacked by the cache poisoning attack, the IPSec or the TSIG is to actually guarantee integrity and authentication of the “fake response”. And it needs to be pointed out that a poisoning attack on a single ISP DNS recursive server can affect numerous users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.
 
To give a countermeasure, the response from a recursive sever might as well be cached in form of both plaintext and ciphertext which is generated by the very recursive server. That’s to say, once a certain DNS resource record arrives from an authoritative name-server, the recursive sever should encrypt the DNS response and then cache it right away before the potential cache poisoning attack. If the data exchanged between local recursive server and authoritative name-server is secured by DNSSEC, a similar course should be followed by the recursive sever right after the DNSSEC verification.
 
Once the requester, a PC typically, gets the response in dual forms, it can then verify the correlation between them. If so, even the attacker has poisoned the DNS information cache, yet the two forms of poisoned cache, plaintext and ciphertext, could not be in accordance with each other. Consequently, the verification to them by a requester will never pass and then the phishing would be avoided.
 
With respect to the generation and the distribution of the key for the ciphertext mentioned above, further deliberation is needed.
 
Any critical will be appreciated.

2009-04-30 

madi 

发件人： Stephane Bortzmeyer 
发送时间： 2009-04-23  19:40:15 
收件人： Scott Rose 
抄送： [email-masked]; dnsop 
主题： Re: dns data exchanged between host and local dns-sever 
 
On Thu, Apr 23, 2009 at 07:10:13AM -0400,
 Scott Rose  <[email-masked] > wrote

---

From: [email-masked]
Date: Thu, 30 Apr 2009 09:25:09 +0000

On Thu, Apr 30, 2009 at 02:15:48PM +0800, madi wrote:
> Hi, Stephane.
>  
> To give a countermeasure, the response from a recursive sever might as well be cached in form of both plaintext and ciphertext which is generated by the very recursive server. Thatbs to say, once a certain DNS resource record arrives from an authoritative name-server, the recursive sever should encrypt the DNS response and then cache it right away before the potential cache poisoning attack. If the data exchanged between local recursive server and authoritative name-server is secured by DNSSEC, a similar course should be followed by the recursive sever right after the DNSSEC verification.
>  

	this presumes that the query to the authoritiative server is not intercepted and
	replied to by a rogue nameserver -first-....

	the primary benefit to DNSSEC is that it protects the integrity of the data - regardless
	of where it is coming from.  if the cache is corrupted/poisoned, the data will fail to 
	validate - and depending on your validator response - will fail resolution.

	what is missing/needed here is a way for a validator to mark a recursive server as "bad"
	and find/select an alternate server...  which is outside the scope of the DNSSEC design.

> Once the requester, a PC typically, gets the response in dual forms, it can then verify the correlation between them. If so, even the attacker has poisoned the DNS information cache, yet the two fo…

	DNSSEC already does this. 
> ed;6d::o< Stephane Bortzmeyer 
> eif6i4o< 2009-04-23  19:40:15 
> f6d;6d::o< Scott Rose 
> f
io< [email-masked]; dnsop 
> d8;i"o< Re: dns data exchanged between host and local dns-sever 
>