Subject: [DNSOP] DNS vulnerabilities

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 01:16:29 +0200

Hello,

I have gathered some vulnerabilities in the current DNS security approaches
such as DNSSEC and etc.  We think it is useful to have a survey of existing
vulnerabilities or any new vulnerabilities so that we can address those
issues in other standard RFC.  This is why we plan to write a new
informational draft.  

There is currently one old RFC that address the DNS vulnerabilities:
http://tools.ietf.org/html/rfc3833 

So, we welcome any ideas about this work.

Thanks,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 01:28:10 +0200

Hi Bill,

Thanks for your message.

> are your new collection, DNS vulnerabilities, configuration mistakes, or
> implementation faults?

Currently I collected some information regarding DNS vulnerabilities and
some about configuration mistakes. But I haven't included anything regarding
implementation faults yet. I guess it is also good to have a section about
this. 
Any thought?

-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

---

From: [email-masked]
Date: Fri, 25 Oct 2013 23:21:03 +0000

are your new collection, DNS vulnerabilities, configuration mistakes, or implementation faults?

/bill

On Sat, Oct 26, 2013 at 01:16:29AM +0200, Hosnieh Rafiee wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: [email-masked]
Date: Sat, 26 Oct 2013 00:32:36 +0000

its hard to distinguish an implementation error and a DNS protocol error, so yes, it might
be a very good idea to triage your failures properly.

/bill

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 12:12:11 +0200

Thank you again, Bill. 

>  it's hard to distinguish an implementation error and a DNS protocol
error, so
> yes, it might be a very good idea to triage your failures properly.

Yes I guess it's really a good comment to consider in this work. 

@list: Any other ideas?

-----------smile----------
Hosnieh

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 26 Oct 2013 20:59:42 +0900

> issues in other standard RFC.  This is why we plan to write a new

As was discussed recently in IETF ML, a serious vulnerability of,
so called, DNSSEC is lack of secure time.

In the discussion, there is no practical solution against it,
though some security novices innocently believed GPS time were
automagically secure.

That is, so far, there is no way to have really secure DNSSEC.

						Masataka Ohta

> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
>

---

From: Jim Reid <[email-masked]>
Date: Sat, 26 Oct 2013 13:11:26 +0100

On 26 Oct 2013, at 12:59, Masataka Ohta <[email-masked]> wrote:

> a serious vulnerability of, so called, DNSSEC is lack of secure time.
> some security novices innocently believed GPS time were automagically secure.

Rubbish!

If good timekeeping matters so much to DNSSEC, there are plenty of sources of reliable time. For most people, NTP will be good enough. The paranoid might choose Secure NTP. The really paranoid will have multiple time sources other than GPS: eg the radio clocks operated by many national standards institutes and/or the EU, Russian and Chinese(?) equivalents of GPS. The really, really paranoid will operate their own atomic clocks.

---

From: [email-masked]
Date: Sat, 26 Oct 2013 12:40:24 +0000

> If good timekeeping matters so much to DNSSEC, there are plenty of sources of reliable time. For most people, NTP will be good enough. The paranoid might choose Secure NTP. The really paranoid will…

	In Ohta-sans world, secure hinges on being idempotent from the silicon,
	the assembler, compiler, binaries and data.  If any of these attributes
	is or can be compromised - its not secure.

	DNSSEC depends on time e.g. not idempotent == not secure.

	What really is happening is that DNSSEC is a risk management tool.
	DNSSEC can measureably reduce the risk of bad data.  It does introduce
	new risk, in the form of timeing attacks, but the tradeoffs generally 
	are presented as acceptable to most folk.

/bill

---

From: Ted Lemon <[email-masked]>
Date: Sat, 26 Oct 2013 14:59:59 +0000

> If good timekeeping matters so much to DNSSEC, there are plenty of sources of reliable time. For most people, NTP will be good enough. The paranoid might choose Secure NTP. The really paranoid will…

While I don't actually disagree with your basic point, I don't think you should gloss over the problem of the RTC-less home gateway that can't trust the network, or, similarly, the constrained device with the same issue.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 27 Oct 2013 07:55:49 +1100

> That is, so far, there is no way to have really secure DNSSEC.

DNSSEC requires everyone to be using roughly the same concept of
the current time.  It doesn't have to be particularly accurately
set.  You don't need to run NTP or anything else to keep it in sync.

Just set the clock on your validating resolver the way you would
your wrist watch once a year/month and as long as it is has a battery
backup you will be fine.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Oct 2013 06:08:16 +0900

Jim Reid wrote:

> If good timekeeping matters so much to DNSSEC, there are plenty of
> sources of reliable time. For most people, NTP will be good enough.

Very good point.

Then, your problem is that for most people, plain DNS *IS* good
enough and that DNSSEC+NTP does not make it any better.

> The paranoid might choose Secure NTP.

Secure NTP does not solve the operational problem of automatic
key roll over for secure NTP itself.

> The paranoid might choose Secure NTP. The really paranoid will
> have multiple time sources other than GPS: eg the radio clocks
> operated by many national standards institutes and/or the EU,
> Russian and Chinese(?) equivalents of GPS.

The problem is that a quartz clock combined with several
transmiters is good enough to fake GPS data.

> The really, really
> paranoid will operate their own atomic clocks.

While atomic clocks are not very expensive, they don't need
them, because only the really, really, really paranoid use
DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Oct 2013 15:30:36 +0900

Ted Lemon wrote:

> While I don't actually disagree with your basic point, I don't
> think you should gloss over the problem of the RTC-less
> home gateway that can't trust the network, or, similarly,
> the constrained device with the same issue.

The constraint is in users. That is, most home users can't
configure there home gateways.

Thus, even if home gateways have their own RTCs, they must
synchronize their RTCs with some factory configured external
clocks, regardless of time differences between the RTCs and
the external clocks.

Otherwise, most home users can do nothing if the difference
is large.

						Masataka Ohta

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 27 Oct 2013 10:33:40 +0100

> > > I have gathered some vulnerabilities in the current DNS security
> > > approaches such as DNSSEC and etc.  We think it is useful to have a
> > > survey of existing vulnerabilities or any new vulnerabilities so
> > > that we can address those issues in other standard RFC.  This is why
> > > we plan to write a new informational draft.
> >
> > As was discussed recently in IETF ML, a serious vulnerability of, so
> > called, DNSSEC is lack of secure time.
> >
> > In the discussion, there is no practical solution against it, though

I guess this problem is also true for any protocol that uses timestamp in
their signature and not DNSSEC specific.  Because the nodes need to consider
clock skew (for at least a few seconds) and this is actually where the
attacker can attack the node (replay attack.... )

-----------smile----------
Hosnieh

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Oct 2013 13:07:27 +0900

Hosnieh Rafiee wrote:

> their signature and not DNSSEC specific.

Not necessarily. Some security protocol can safely assume
clocks of related equipments are manually managed by skilled
operators, which is not the case with DNS clients.

Then, plain DNS modified to have 32 (or 64?) bit messages
ID is as secure as DNSSEC.

> Because the nodes need to consider

If the skew were few seconds, it is not a security problem
for DNS.

The problem is that, without human intervention by skilled
operators, clocks can be very inaccurate.

Then, a compromised and expired zone key can be used for
arbitrary data of the zone, which is more serious than
replay attack.

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Oct 2013 15:41:31 +1100

> operators, which is not the case with DNS clients.

Most people are capable of setting the clocks on their laptops,
phones and other portable equiment which all should be validating
responses.  Most people are capable of setting clocks on their
desktop machines which should be validating responses.

If the router takes a leap of faith w.r.t. time then it just shouldn't
set AD on its responses though should still validate responses.
This is significantly better than not validating responses and
unless all the DNS responses are being compromised will result in
lots of DNSSEC validation failures on responses.

Downstream validators will not be able to get valid answers for the
forged data (as the forged data will be cached) but will get valid
answers for the unforged data (as this will not be cached but will
be returned with cd=1) with a compromised time.  This makes the
attack visible.

> ID is as secure as DNSSEC.

No it is not as there is well known examples of ISP's and hotspots
poisoning DNS responses.  This is not to say we shouldn't be using
larger id's as they will make it less important to randomise ports.

> If the skew were few seconds, it is not a security problem

Nor even hours if signers set the inception time to more than a
hour in the past.

> operators, clocks can be very inaccurate.

And the effects of bad clocks will be seen once stub resolvers
routinely validate responses.

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Oct 2013 08:24:18 -0400

> ID is as secure as DNSSEC.

How does a 32 or 64 bit message ID protect you from on-path MITM/injection attacks?

Protecting the communication channel does not equal protecting the data.

Regards,
-drc

---

From: Marc Lampo <[email-masked]>
Date: Mon, 28 Oct 2013 16:57:46 +0100

How could a "local time problem" lead to using an "expired (zone) key" for
arbitrary data of the zone ?
~ DNSKEY info itself does not expire - only signatures have expiration date
~ admitting a "local time problem" can allow for replay attacks
   in the sense of : "making a validating resolver believe the RRSIG is
still within validity time".
   Do not overlook the fact that the public key is still required to
perform the validation itself !

So, I think you actually make a case for not letting "no longer used"
DNSKEY information linger in the zone file.

Overall, assuming a DNS reply for www.example.com. with a signed but
expired signature,
would also need
  the no longer used zone signing key
  signed with the key signing key (possibly also expired)
(and things get even more complicated if the key signing key has been
rotated as well)

So, there is still a lot of value in validating DNSSEC responses.

Kind regards,

Marc

On Mon, Oct 28, 2013 at 5:07 AM, Masataka Ohta <
[email-masked]> wrote:

> (partly removed)

---

From: Evan Hunt <[email-masked]>
Date: Mon, 28 Oct 2013 18:40:28 +0000

> arbitrary data of the zone ?

There is a genuine theoretical concern here, but IMHO it's unrealistic. 

Imagine some shadowy omnipotent organization has tapped your connection
to the internet and controls every packet you send and receive.  Your
router box (or other embedded device lacking an RTC battery) boots and
requests the current time via NTP.  The bad guys send a forged response
indicating a time in the past, then they answer all DNS queries by
replaying data that were captured at that time: the answers *used* to
be valid, but they aren't anymore.  Now suppose this no-longer-valid
data includes a TLSA record for a certificate that's been compromised
and revoked since then...?

I can't see this as realistic for several reasons - among them, that
it's easily detectable by anyone who happens to compare the clock on
their router to what it says on their calendar, and I presume a shadowy
omnipotent organization would have a strong preference for undetectability.
I'd prefer "provably impossible" to "insanely impractical" if I had a
choice in the matter, but the truth is, any adversary with the resources to
pull this off would certainly have cheaper alternatives.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Oct 2013 15:22:55 +0900

> desktop machines which should be validating responses.

Because they have buttons and displays to do so, which is not
the case for a home router as a black box.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Oct 2013 15:24:26 +0900

> How does a 32 or 64 bit message ID protect you from on-path

Tell it to those who are asserting plain NTP were good enough
for DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Oct 2013 16:48:54 +0900

Hosnieh Rafiee wrote:

> issues in other standard RFC.

Another security problem is caused by a fundamental fallacy
of PKI that CAs were trusted third parties.

If a zone administrator is legally forced to disclose secret
key of the zone or forge a certificate for a child zone of
the zone, the zone is not secure at all.

Thanks to Snowden,I can safely state such enforcement
plausible without being called a paranoia.

The problem can be avoided if we modify DNSSEC require
multiple signatures from multiple organizations in several
countries such as Russia, China etc. at least for root
and TLD zones.

					Masataka Ohta

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 30 Oct 2013 15:57:06 +0800

> From: Masataka Ohta
> Date: 2013-10-29 14:22
> To: Mark Andrews
> CC: 'Andrew Sullivan'; DNSOP; Hosnieh Rafiee; dnsext
> Subject: Re: [DNSOP] [dnsext] DNS vulnerabilities
> Mark Andrews wrote:

> the case for a home router as a black box.

I am wondering is it possible to provide a mechanism for people manually modifying the clock 
of home routers just as people setting the clock of their laptops. And in such mechanism, 
the clock of the home router is modified by human being while in NTP (Network Time Protocol) 
that is modified by a NTP server. 

> Masataka Ohta

Guangqing Deng
CNNIC

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Oct 2013 21:18:35 +0900

Guangqing Deng wrote:

> of home routers just as people setting the clock of their laptops.

A problem is that there are too much ways to do so such as

	http://192.168.0.*
	http://192.168.1.*

none of which is familiar to most home users.

IPv6 makes the problem worse.

The real problem, however, is that most home users can't identify
the cause (inaccurate clock) why their home routers stop working,
which means they won't try to adjust the clock at all, even if
they knew how to do it.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Oct 2013 12:33:39 +0900

> issues in other standard RFC.  This is why we plan to write a new

While this is, in theory, a known vulnerability, it is
still surprising that USG actively used it.

Mocana Purges NSA-Compromised Key-Generation Scheme from Its
Popular Nanocrypto Embedded Security Engine
http://www.businesswire.com/news/home/20131016005500/en
SAN FRANCISCO--(BUSINESS WIRE)--Mocana, the app security leader,
issued a security advisory and announced an update to its
NanoCrypto™ embedded security engine software
(www.mocana.com/nanocrypto) that removes the Dual Elliptic
Curve Deterministic Random Bit Generator (Dual_EC_DRBG)
algorithm, an algorithm that was previously promoted as a
cryptographically secure key generation method by the National
Institute of Standards and Technology (NIST). Mocana’s action
is the result of recent Edward Snowden document revelations that
the Dual_EC_DRBG algorithm contains a vulnerability that likely
enables US intelligence agencies to easily decrypt communications
protected with the algorithm. The algorithm was designated as a
standard (SP 800-90A) by NIST in 2006, at least in part because
of endorsement and promotion by the NSA.

						Masataka Ohta

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 31 Oct 2013 09:59:18 +0100

Hi Masataka,

Thank you for your useful inputs.

> While this is, in theory, a known vulnerability, it is still surprising that USG
> actively used it.
> 
> Mocana Purges NSA-Compromised Key-Generation Scheme from Its Popular
> Nanocrypto Embedded Security Engine
> SAN FRANCISCO--(BUSINESS WIRE)--Mocana, the app security leader, issued
> a security advisory and announced an update to its NanoCrypto™ embedded
> security engine software
> (www.mocana.com/nanocrypto) that removes the Dual Elliptic Curve
> Deterministic Random Bit Generator (Dual_EC_DRBG) algorithm, an
> algorithm that was previously promoted as a cryptographically secure key
> generation method by the National Institute of Standards and Technology
> (NIST). Mocana’s action is the result of recent Edward Snowden document
> revelations that the Dual_EC_DRBG algorithm contains a vulnerability that
> likely enables US intelligence agencies to easily decrypt communications
> protected with the algorithm. The algorithm was designated as a standard
> (SP 800-90A) by NIST in 2006, at least in part because of endorsement and
> promotion by the NSA.
> 

Since hash functions are used in DNSSEC (NSEC3), I have a section about the evaluation of hash functions (SHA1,...). But I guess what you mentioned here is really important. So, do you think it is useful only to focus on the algorithms used in DNS or just explain the known/found vulnerabilities of all cryptographic algorithms because maybe for encryption/decryption they might be used in future/ or are using? Do you think it will be relevant to this document or it can be another informational document only discuss about the  vulnerabilities of cryptographic algorithms? 

Thanks again

-----------smile----------
Hosnieh
… success is a journey, not a destination….
You cannot change your destination overnight, but you can change your direction ... Focus on the journey

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 Oct 2013 19:36:46 +0000

> so called, DNSSEC is lack of secure time.

I have the beginnings of a solution to this problem. It is based on using
tlsdate, which gets the time from a server with minimal risk of
interference by a man-in-the-middle. If you get the time from several
diverse servers you can be very sure you have the right time if enough
of them agree. You can choose the size of a quorum according to your
security and robustness requirements. Agreement is determined in a similar
way to NTP's clock select algorithm, which separates falsetickers from
truechimers.

http://fanf.livejournal.com/128861.html
 - introductory article

https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git
 - rough proof of concept implementation

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 01 Nov 2013 15:29:12 +0900

Tony Finch wrote:

> interference by a man-in-the-middle.

TLS is another PKI and is inherently insecure as CAs can be
compromised.

> How does a 32 or 64 bit message ID protect you from on-path

we should assume local ISP can be compromised.

Then, as compromising a CA is just as easy as compromising
an ISP, PKIs, including but not limited to DNSSEC and TLS,
are inherently insecure.

Worse, tlsdate has a chicken and egg problem. Without secure
clock, how can you be sure that certificate for tlsdate is
still valid?

> If you get the time from several
> of them agree.

It is not more secure than using multiple NTP servers with
plain NTP.

						Masataka Ohta

---

From: Evan Hunt <[email-masked]>
Date: Fri, 1 Nov 2013 06:35:52 +0000

> TLS is another PKI and is inherently insecure as CAs can be

True, but Tony's quorum-based approach could be made exhaustive enough
that the adversary would have to have compromised *every* CA.  If they
can do that, I'm not sure any realistic defense is possible anyway.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 01 Nov 2013 15:39:44 +0900

Hi, Hosnieh,

> Do you think it will be relevant to this document or it can be
> another informational document only discuss about the
> vulnerabilities of cryptographic algorithms?

As I said, it is a known vulnerability. That is, we don't
need a generic new document very much.

However, Snowden taught us that we must avoid any fancy
cryptography strongly promoted by NIST, including all the
EC related ones, which may be documented somewhere.

						Masataka Ohta