Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Sep 2013 17:59:52 -0400

[cc'ed to a more approriate IETF wg] 
On Sep 10, 2013, at 11:55 AM, Jim Gettys <[email-masked]> wrote:

> Ted T'so referred to a conversation we had last week. Let me give the background.
> 
> Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki).  Of course, we both want things other than just bufferbloat, as you can see by looking at that page (and you want to run in place of what you run today, given how broken and dated home router firmware from manufacturers generally is).  Everything possible gets pushed upstream into OpenWrt as quickly as possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways.
> 
> I was frustrated by Homenet's early belief's (on no data) that lots of things weren't feasible due to code/data footprint; both Dave and I knew better from previous work on embedded hardware.  As example, Dave put a current version of bind 9 into the build (thereby proving that having a full function name service in your home router was completely feasible; that has aided discussions in the working group) since.
> 
> We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home:
> 
> 1) DNSSEC needs to have the time within one hour.  But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them).  
> 
> So how do you get the time after you power on the device?  The usual answer is "use ntp".  Except you can't do a DNS resolve when your time is incorrect.  You have a chicken and egg problem to resolve/hack around :-(.
> 
> Securely bootstrapping time in the Internet is something I believe needs doing....  and being able to do so over wireless links, not just relying on wired links.
> 
> 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain).  
> 
> Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do.  These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of "the enemy of the good is the perfect", but certainly I'm now much more paranoid than I once was.
> 
> See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj
> 
> Jim
> 

My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode
wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. 
see: https://www.dnssec-deployment.org/index.php/2012/03/a-validating-recursive-resolver-on-a-70-home-router/ 
We also discovered that some cheap devices like this will do NTP at startup and never again that combined with long up-time and bad clocks 
caused the Validators to start rejecting signatures due to the time on the signatures. 

The big issue is that validator implementors assume that it runs on good hardware with good links, thus it is safe to enable DNSSEC out of the gate.
We need either have resolvers come up in recursive mode and tool like dnsec-trigger or our scripts change the behavior to validator after that has been
deemed safe, or build the checking into the validators. 

The same can be said of devices that have been installed from media or have been turned off for a long time (say month or more), in these cases 
starting up in validating mode only only turns the device into a brick. 

	Olafur

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 10 Sep 2013 22:08:21 +0000

Have you looked at integrating NTP code (and an internal "clock") into the Unbound running on the OpenWrt routers?
(If you want something done right, sometimes you have to do it yourself, and all that.)

Even if the clock on this hardware is not all that great, is there any functionality which can give reasonably reliable status?
Things like, "How many seconds have elapsed since I last asked?", and basically run on a combination of occasional NTP plus kind of a temporal "inertial guidance", modulo accumulated error?

Good enough for DNSSEC?

Brian

From: Olafur Gudmundsson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 10, 2013 5:59 PM
To: Jim Gettys <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> TF" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[cc'ed to a more approriate IETF wg]
On Sep 10, 2013, at 11:55 AM, Jim Gettys <[email-masked]<mailto:[email-masked]>> wrote:

Jim

Olafur

---

From: Joe Abley <[email-masked]>
Date: Tue, 10 Sep 2013 18:17:42 -0400

> [cc'ed to a more approriate IETF wg] 

... and I'll gratuitously mention draft-jabley-dnsop-validator-bootstrap here too, since it addresses exactly this topic.

Joe

---

From: Evan Hunt <[email-masked]>
Date: Tue, 10 Sep 2013 22:45:18 +0000

On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
> My colleagues and I worked on OpenWrt routers to get Unbound to work
> there, what you need to do is to start DNS up in non-validating mode wait
> for NTP to fix time, then check if the link allows DNSSEC answers
> through, at which point you can enable DNSSEC validation. 

That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
also discussed hacking NTP to set the CD bit on its initial DNS queries,
but I don't think any of the code made it upstream.

My real recommendation would be to run an NTP pool in an anycast cloud of
well-known v4 and v6 addresses guaranteed to be reliable over a period of
years. NTP could then fall back to those addresses if unable to look up the
server it was configured to use.  DNS relies on a well-known set of root
server addresses for bootstrapping; I don't see why NTP shouldn't do the
same.

(Actually... the root nameservers could *almost* provide a workable time
tick for bootstrapping purposes right now: the SOA record for the root
zone encodes today's date in the serial number.  So you do the SOA lookup,
set your system clock, attempt validation; on failure, set the clock an
hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Sep 2013 11:17:38 +1200

On 11/09/2013 09:59, Olafur Gudmundsson wrote:
...
> wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation.

Hopefully you also flush the DNS cache as soon as NTP runs. Even so,
paranoia suggests that a dodgy IP address might still be cached in
some app.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Sep 2013 09:30:46 +0900

Olafur Gudmundsson wrote:

>> So how do you get the time after you power on the device?  The usual
>> answer is "use ntp".  Except you can't do a DNS resolve when your
>> time is incorrect.  You have a chicken and egg problem to
>> resolve/hack around :-(.

It is one reason why DNSSEC does not worth deploying

> wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation.

That's not secure, especially when some (root, TLD, etc.) expired
zone key is/was compromised.

						Masataka Ohta

---

From: David Morris <[email-masked]>
Date: Tue, 10 Sep 2013 17:17:14 -0700 (PDT)

> paranoia suggests that a dodgy IP address might still be cached in

I think you can avoid that issue by having the device not pass traffic
until the DNSSEC validation is enabled. Only the device needs the special
permissive handling for this to work.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 11 Sep 2013 10:13:55 -0400

> paranoia suggests that a dodgy IP address might still be cached in

Flushing cache is a good idea, and dnssec-trigger does this when it "upgrades" the unbound from recursor to validator. 

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 11 Sep 2013 10:16:24 -0400

> permissive handling for this to work.

You mean only allow NTP and DNS traffic in the beginning, until checks are done? 
In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that
only helps for reboot. 

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 11 Sep 2013 10:19:30 -0400

> but I don't think any of the code made it upstream.

Not sure if this will work in all cases, as a paranoid resolver might 
only ignore the CD bit for the actual answer not for the DNS records needed
to navigate to the answer. 

> server addresses for bootstrapping; I don't see why NTP shouldn't do the

This is something worth suggesting, and 

> -

RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a 
replay attack or a forgery, 

	Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Sep 2013 07:30:23 -0700

> replay attack or a forgery, 

This can actually do it down to 1s precision except in the case of a replay attack with a dynamically signed name (and if you are facing a replay attack, you can't trust NTP anyway!):

E.g., this name:

dig +dnssec 10sec100ttlsig.netalyzr-dnssec.com @8.8.8.8

has a RRSIG that expires in +10 seconds (ALWAYS), but has a TTL on the record that expires in 100 s.  This is an example name on my server designed for allowing single-lookup clockdrift testing on DNSSEC validators.

(The signature is also generated on-the-fly every second its requested, and a subsequent addition will include the ability to add a NONCE to guarantee cache-busting, too).

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 11:42:11 -0400 (EDT)

> In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that

And if you think of laptop and/or phone, add "hotspot detection" to this
isolation mode. It's harder because it needs a "private browser window"
type state.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 11:43:23 -0400

OK lets consider the trust requirements here.

1. We only need to know the current time to an accuracy of 1 hour.

2. The current time is a matter of convention rather than a natural
property. It is therefore impossible to determine the time without
reference to at least one trusted party.

2a) A trusted party that asserts that the current time is set to a date in
the future can perform a denial of service attack on a relying party but
one that is easily detected.

2b) It is a simple matter for the trusted party to provide a signed
assertion that the current time is after the Date-Time X. The hard part is
ensuring that the relying party can access an up to date version of the
current time assertion.

2c) DNSSEC already provides an abundance of such assertions. If the
signatures on the .com zone are claiming a date in the future then the
whole viability of DNSSEC collapses.

3) A relying party thus requires a demonstration that is secure against a
replay attack from one or more trusted parties to be assured that the time
assertion presented is current but this need not necessarily be the same as
the source of the signed time assertion itself.

4) In the case of DNSSEC the window of vulnerability is actually fairly
small since rewinding the time to a date in the past only helps an attacker
if they had compromised the system on that date.

The real design decision is who you decide you are going to rely on for
(3). TLS is proof against replay attack due to the exchange of nonces.

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 11:49:05 -0400

> 1. We only need to know the current time to an accuracy of 1 hour.

[RRSIG expiration times are specified with a granularity of a second, right?

I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think "1 hour" needs some qualification.]

> 2. The current time is a matter of convention rather than a natural property. It is therefore impossible to determine the time without reference to at least one trusted party.
> 
> 2a) A trusted party that asserts that the current time is set to a date in the future can perform a denial of service attack on a relying party but one that is easily detected.
> 
> 2b) It is a simple matter for the trusted party to provide a signed assertion that the current time is after the Date-Time X. The hard part is ensuring that the relying party can access an up to date version of the current time assertion.
> 
> 2c) DNSSEC already provides an abundance of such assertions. If the signatures on the .com zone are claiming a date in the future then the whole viability of DNSSEC collapses. 
> 
> 3) A relying party thus requires a demonstration that is secure against a replay attack from one or more trusted parties to be assured that the time assertion presented is current but this need not necessarily be the same as the source of the signed time assertion itself.
> 
> 4) In the case of DNSSEC the window of vulnerability is actually fairly small since rewinding the time to a date in the past only helps an attacker if they had compromised the system on that date.

[or if they had intercepted, stored and replayed a signed response at a later time when the current response would be different]

> The real design decision is who you decide you are going to rely on for (3). TLS is proof against replay attack due to the exchange of nonces. 

I think that's deeper than where we are right now. Before we consider mechanisms for gauging the accuracy of a local clock, we need consensus on the general approach, e.g. the state machine implied by draft-jabley-dnsop-validator-bootstrap or something different but analogous.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 12:08:18 -0400 (EDT)

> I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think "1 hour" needs some qualification.]

The 1h came from the shortest RRSIG validity time in the chain to get to
pool.ntp.org, but performing a handful of queries now, I cannot find
that magical RRSIG with the 1h validity period.

Note: I also once ran into bad clocks due to dual boot systems with
Windows and Daylight Savings Time, so I explicitely set inception time
to -2h. One hour is not enough on doubly broken systems.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 12:18:10 -0400

On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters <[email-masked]> wrote:

>> I appreciate that most people are generous with signature inception and
>> expiration times in order to facilitate clock skew on validators, but I
>> think "1 hour" needs some qualification.]
>>
>

The DNS is the naming infrastructure of the Internet. While it is in theory
possible to use the DNS to advertise very rapid changes to Internet
infrastructure, the practice is that the Internet infrastructure will look
almost exactly the same in one hour's time as it does right now.

Using DNS data from 24 hours earlier might create reliability issues but
should never introduce a security risk. Anyone who is relying on the DNS
for data that is more time sensitive than 1 hour is doing it wrong.

-- 
Website: http://hallambaker.com/

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Sep 2013 09:26:13 -0700

On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> The DNS is the naming infrastructure of the Internet. While it is in theory possible to use the DNS to advertise very rapid changes to Internet infrastructure, the practice is that the Internet infrastructure will look almost exactly the same in one hour's time as it does right now.
>  
> Using DNS data from 24 hours earlier might create reliability issues but should never introduce a security risk. Anyone who is relying on the DNS for data that is more time sensitive than 1 hour is doing it wrong.

I disagree.  DNSSEC is not just DNS: its the only available, deployed, and (mostly) accessible global PKI currently in existence which also includes a constrained path of trust which follows already established business relationships.

Dynamic DNSSEC applications, where signatures are generated on the fly, are almost certainly going to be developed to utilize this infrastructure.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 15:38:21 -0400

On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver <[email-masked]
> wrote:

> > The DNS is the naming infrastructure of the Internet. While it is in
> theory possible to use the DNS to advertise very rapid changes to Internet
> I disagree.  DNSSEC is not just DNS: its the only available, deployed, and
> (mostly) accessible global PKI currently in existence which also includes a
> constrained path of trust which follows already established business
> relationships.
>

Except that virtually nobody uses DNSSEC and most of the registrars don't
support it.

And then there is that other PKI that is actually used to support a
trillion odd dollars worth of global e-commerce per year.

DNSSEC has been about to exist ever since I started on the Web over two
decades ago now. It is still not in use to support any business
transactions. So to present it as the only PKI when it isn't yet deployed
is showing a distinct lack of common sense and acceptance of reality.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Sep 2013 12:56:27 -0700

On Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Except that virtually nobody uses DNSSEC and most of the registrars don't support it.

I strongly disagree:

I had an easier time registering my DNSSEC test domain's DS records with the registrar than the nameservers themselves, using an obnoxious company that sponsors a NASCAR driver and has obnoxious TV ads.

Comcast and Google Public DNS both validate DNSSEC on all requests.

A small minority of clients can't fetch DNSSEC records, but most actually can, either through one of the recursive resolvers or over the Internet.

> And then there is that other PKI that is actually used to support a trillion odd dollars worth of global e-commerce per year.

Which the NSA is man-in-the-middling with abandon, in due to no-small-part the lack of a constrained path of trust.  Google has effectively given up on the TLS PKI for their own use in Chrome: they hardcode the Google sub-CA.

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Sep 2013 10:39:20 +0100

> reference to at least one trusted party.

Preferably more than one so you can use quorum agreement and minimize the
amount of trust you put in any single time reference.

> if they had compromised the system on that date.

So if you rely on RRSIG timestamps or SOA serial numbers to get the time,
an attacker that manages to compromise DNSSEC can replay that compromise
indefinitely.

> (3). TLS is proof against replay attack due to the exchange of nonces.

Right.

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: Tony Finch <[email-masked]>
Date: Thu, 12 Sep 2013 13:27:28 +0100

Theodore Ts'o <[email-masked]> wrote:
>
> Their dynamic with their users and the market is the same as with CA's
> --- the market virtually guarantees a race to the bottom in terms of
> quality and prices.  So beyond replacing names like "Comodo" with "Go
> Daddy", what benefit do you actually think would accrue?  You'll still
> be dealing with a self-service security model, probably using e-mail
> based password recovery.

But if you care about security you can - with useful effect - choose a
registrar with better security processes, and you can use a registry lock
to prevent other registrars from undermining that security.

There isn't a way to prevent other CAs undermining your security, so
choosing a "more secure" CA has no useful effect. (Certificate
Transparency should help, though.)

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Sep 2013 10:22:10 -0400 (EDT)

On Thu, 12 Sep 2013, Theodore Ts'o wrote:

> More importantly, what problem do people think DNSSEC is going to
> solve?
>
> It is still a hierarchical model of trust.  So at the top, if you
> don't trust Verisign for the .COM domain and PIR for the .ORG domain
> (and for people who are worried about the NSA, both of these are US
> corporations), the whole system falls apart.

Any co-ercing that happens has to be globally visible, if the target
ensures he is using "random" nameservers to query for data. This should
be detectable, and I hope that high value domains (like eff.org) ensure
that they are monitoring DNS answers to see if any forged-with-private-key
answers are seen in the wild. (eg RIPE Atlas?) Once we have proof of that,
we can ponder about how to cut the US Government out of our DNS roots.

(sadly, eff.org is still not signed and has no TLSA record. Likely due
to their registrar not supporting it, but at least they could do DLV)

> And even if you believe Verisign and PIR are a paragons of virtue
> which are incorruptible (even when in a dark room when no one can see,
> as the old Chinese saying goes), what about all of the registrars?
>

As Tony said. You can pick a non-bottom one.

> Basically, DNSSEC maps almost identically to the previously unsolved
> problem.

Not at all - targetted attacks with CAs are easy. Unlike with DNSSEC.

Furthermore, TLDs could institute a delay mechanism with respect to
updating KSK/DS record so a compromised Registrar requesting an updated
DS won't come into effect immediately, and the Registrant has time to
react.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 15:01:36 +0000

> corporations), the whole system falls apart.

This isn't _quite_ true.   DNSSEC supports trust anchors at any point in the hierarchy, and indeed I think the right model for DNSSEC is that you would install trust anchors for things you really care about, and manage them in the same way that you manage your root trust anchor.   E.g., you'd install a trust anchor for your employer, and your bank, and maybe your local town government.   This is all future UI work, of course.

Furthermore, if the root key is compromised and that is then used to substitute a bogus key, it isn't that hard to notice that this has happened, and indeed we ought to be systematically noticing these things.   So hacking the root key is certainly a valid threat, but there is a great deal more transparency in the DNSSEC system than in the TLS PKI, and that should mean that the system is more robust in the face of this kind of attack.

That said, multiple independent systems used together, managed separately, will likely also add value, so TLS PKI + DNSSEC is probably better than TLS PKI or DNSSEC separately, modulo DoS attacks, which in this case would be easily detected and fixed.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Sep 2013 11:17:09 -0400 (EDT)

On Thu, 12 Sep 2013, Theodore Ts'o wrote:

>> ensures he is using "random" nameservers to query for data.
>
> Not necessarily.  First of all, an active attacker located close to
> the target can simply replace the DNS replies with bogus records,

Not if I run DNS over TCP through tor. That's why I said "random"
servers. Are they going to after a single target by being upstream of
all the tor exit nodes? Even if they did, we should just run monitors
for our own zones that also query for that data using tor. They won't
know the difference between the monitor and their target.

> signed by the registrar's key which was either coerced or stolen by
> the NSA's Key "Recovery" Service.  Secondly, if the web site has all
> of its nameservers run by the same organization (i.e., GoDadddy's DNS
> service), the nameservers could be set up to return the bogus DNS
> records only to specific IP addresses or specific IP ranges.

See above.

> Finally, if you think the target can try to find random caching
> nameservers all across the networ to use, (a) there are certain
> environments where this is not allowed --- some ISP's or hotel/coffee
> shop/airline's networks require that you use their name server, and
> (b) for good and proper reasons, most nameservers have been configured
> not to allow recursive queries to random IP addresses.

See above. But also, you can use various open resolvers. The Fedora
Project even runs a few for dnssec-trigger that are accessable only via
TCP - I'm hoping more people will put up TCP-only open resolvers,
especially with:
https://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query/

> A delay mechanism would only work if the TLD sent a notification of a
> changed KSK/DS record to the Registrant --- but would TLD have access
> to the contact information for the Registrant?

Yes, the TLD runs their Registry with admin-c and tech-c contact
information.

Another method would be for the domain "lock" to get a delay of a few
hours and/or a confirmation message to the registrant if the registrar
changes the lock status.

Paul

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 12 Sep 2013 07:24:00 -0400

Sure, authenticating DNS queries when previously they were completely
insecured is a good thing.  And if the PKI infrastructure for DNSSEC
is different from that of x509 certificate, maybe that increases the
difficulty a little for the attacker.  But I get really worried when
people say that DNSSEC is somehow going to magically solve the PKI
problem.

					- Ted

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 12 Sep 2013 11:07:33 -0400

- Ted

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 12 Sep 2013 08:32:02 -0700

> corporations), the whole system falls apart.

Its also a constrained path of trust, and you can actually chose who you trust.

E.g. your application could be constructed to look up both "{data}.dnssec-info-domain.com" and "{data}.dnssec-info-domain.ru".  Only if both use the same validated key is the key accepted.

That way, the trust becomes:

1:  The root is trusted

2:  The registrar for .com and .ru don't collaborate, since they must collaborate for the trust to affect the results.

This is a huge difference from SSL, which unless you pin your application to trust only a single CA, you end up having to trust the entire universe of certificate authorities.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 16:46:01 +0000

> not to allow recursive queries to random IP addresses.

The model for this sort of validation is really not on a per-client basis, but rather depends on routine cross-validation by various DNSSEC operators throughout the network.   This will not necessarily catch a really focused attack, so it's not a panacea, but it would limit the scope of the threat for this sort of attack.

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 12 Sep 2013 13:21:40 -0400

On Thu, Sep 12, 2013 at 04:46:01PM +0000, Ted Lemon wrote:
> 
> The model for this sort of validation is really not on a per-client
> basis, but rather depends on routine cross-validation by various
> DNSSEC operators throughout the network.  This will not necessarily
> catch a really focused attack, so it's not a panacea, but it would
> limit the scope of the threat for this sort of attack.

Fair enough, but if the goal is to prevent pervasive surveillance,
simply using a key exchange which provides perfect forward secrecy
will do that, even given the pathetic state of https security given
the realities of the web and the CA's out there.

Still, I agree with the general precept that perfect should not enemy
of the better, and DNSSEC certainly adds value.  I just get worried
about people who seem to think that DNSSEC is a panacea.

   		      		    	       - Ted

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 17:39:38 +0000

> about people who seem to think that DNSSEC is a panacea.

Me too.   It most certainly is not.

---

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 12 Sep 2013 17:49:29 +0000

>as the old Chinese saying goes), what about all of the registrars?

There are vastly different aspects to trust in PKI vs DNSSEC, specifically
about trust vs validation.

In this context, "validation" means, having the domain owner verify that
the DNSSEC and DNS records for their domain, reflect reality.

In order to subvert or redirect a delegation, the TLD operator (or
registrar) would need to change the DNS server name/IP, and replace the DS
record(s).

This would be immediately evident to the domain owner, when they query the
TLD authority (delegation) servers.

In other words, "trust but verify" is an intrinsic part of DNSSEC,
regardless of where in the (trusted) hierarchy delegation occurs, or which
parties are involved in updating the delegation components. DNS can't
scale without delegation and caching. With DNSSEC, all of these elements
support scalable, secure verification and validation.

The ability to monitor this in real time, at centralized locations (TLD
authority servers) scales very well and comes as close to a guarantee of
verifiable security as is practical.

On the other hand, a domain owner currently has no feasible way to
determine that a PKI certificate has been issued for its domain (or any
host in its domain), by any CA other than the CA that issued the "real"
certificate. PKI certificates are tied to names, not IP addresses, and are
not published anywhere. Thus, there is no method, short of querying every
web server, BY NAME, via HTTPS, on the planet, to actively detect "forged"
certificates. If DNSSEC is not used to protect the domain, having a forged
certificate and poisoning DNS caches is all an attacker needs to do - or
being a MitM, which removes the need to poison the cache.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 18:07:00 +0000

> registrar) would need to change the DNS server name/IP, and replace the DS

Someone who possesses the root key could in principle create a fake DNS hierarchy with relatively few strategic changes, and present it only to certain attack targets.   This would be expensive, but not impossible.   It would not work, for example, for dragnet-style surveillance.

---

From: robert bownes <[email-masked]>
Date: Thu, 12 Sep 2013 14:19:01 -0400

Chiming in a bit late here, however, the availability of stratum 1 clocks
and stratum 2 class time data on non IP and/or non interconnected networks
is now so large, I question why one would run NTP outside of the building
in many cases, certainly in an enterprise of any size.

A 1pulse per second aligned to GPS is good to a few ns. Fairly
straightforward to plug into even a OpenWrt type of router. Turn on the pps
in NTP on the router and you are good to go.

On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt <[email-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Sep 2013 14:33:03 -0400

> about people who seem to think that DNSSEC is a panacea.

+1

DNSSEC is a very useful tool. But don't try to make it do things that it
was never designed for.

In particular, I bank with Bank of America,  not bankamerica.com [1]. That
has profound implications for the types of security that are possible with
DNSSEC.

Deployment of DNSSEC permits an Internet user to avoid a downgrade attack
which is vital when you have an Internet that is insecure by default and
security is the exception. That is what I want DNSSEC to address.

Given Jim's original question, having time good to 1 hour seems perfectly
acceptable for purposes of risk mitigation. If you need higher degrees of
assurance then use machines that DO have a built in real time clock. If
that is you think it is reasonable to use the DNS to publish information
that changes more rapidly. When I started doing Internet stuff TTL on DNS
records tended to be three days by default. The registries took 24 hours to
reflect changes.

As a general rule it is much more productive if people respect the fact
that someone just might be suggesting a limitation of an infrastructure
because they want to help solve a problem rather than dismissing everything
as FUD. One of the main reasons it has taken so long to get DNSSEC to this
stage is that honest attempts to make the system practical were treated as
covert sabotage attempts.

[1] Actually I don't it is an example.
-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Sep 2013 14:35:12 -0400

On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon <[email-masked]> wrote:

> Someone who possesses the root key could in principle create a fake DNS
> hierarchy with relatively few strategic changes, and present it only to
> certain attack targets.   This would be expensive, but not impossible.   It
> would not work, for example, for dragnet-style surveillance.
>
>
It would not work for covert dragnet surveillance.

It would work just fine if the attacker did not mind if the surveillance
was detected or actually wanted people to know they were being watched to
intimidate them.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 18:38:02 +0000

On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> It would work just fine if the attacker did not mind if the surveillance was detected or actually wanted people to know they were being watched to intimidate them.

Yup,neither PKI nor DNSSEC address that threat model.   For that you need really good steganography or other covert channels.   Probably too specialized for us.

---

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 12 Sep 2013 19:16:05 +0000

On 9/12/13 2:07 PM, "Ted Lemon" <[email-masked]> wrote:

>certain attack targets.   This would be expensive, but not impossible.
>It would not work, for example, for dragnet-style surveillance.

I presume the "This", in respect to "expensive, but not impossible",
refers to the creating the fake hierarchy.

And that it does not refer to "possesses", as in acquiring the root key.

(Pedantic probability math follows.)

Excluding the direct methods of acquisition, let us consider the level of
effort involved in recreating the root key, by brute force.

We are looking at the average time to find a prime factor of a two-prime
composite number of length 2048 bits, which places it in roughly the 1024
bit range.

===

First, for convenience, I'll give you all the time from the Big Bang until
today, rather than the 5 year KSK key-roll window.
(That's roughly 2^88 seconds.)

Next, I'll also give you a factor of 2^100 for improvements in crypto key
cracking vs prime sieve.

And I'll also give you low-power CPUs at current high-clock-rates. 1 Watt
per core, 2^32 instructions/second.

And I'll also give you 1 guess per clock cycle.

And we'll go with an average prime density of 1/10 (1/(2^4) for LoE
purposes).

I'll now give you all the energy output from Sol, via a Dyson shell (solid
Dyson sphere around our sun, capturing all the energy released), about
3.846 × 1026 Watts, or 2^89 (rounding up to next power of 2). We'll ignore
the age difference of Sol (4.5 B vs 15 B).

There are maybe 10^24 stars, or 2^80. You can have them all.

Even if the vast majority of those were as big as it gets for main
sequence, ie. 500,000 x solar mass, that is only 2^19. Yours, for free.

So, putting a Dyson shell around every star, that has ever been, for all
time up until now, powering as many 1 W cpu cores at 4GHz as possible,
would have produced about enough guesses to cover the range of 2 through
2^(100 + 88 + 89 + 32 + 80 + 4 + 19), or 2^(412).

You would have had to been really lucky to guess one of the prime
components (I.e. to get the private key) -- 1/2^(812), or about 1/10^244.

That is one chance in:
100000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000

(Or, with commas, 
10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,00
0,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,0
00,000,000,000,000,000,000.)

So, in short, "not impossible" would have to be considered an
extraordinary understatement.

And, if you happened to be that lucky, then yes, expensive but not
impossible.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Sep 2013 19:49:17 +0000

> effort involved in recreating the root key, by brute force.

I think we can assume that they would use some fairly subtle attack to get the key, and would not brute force it, unless they know something we do not.   E.g., they might capture it using TEMPEST-style or other EMI-based attacks, or by buying a sufficiency of key holders (which I suspect would be a lot harder at the moment, but might not always be as hard).

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Sep 2013 05:53:54 +0900

Ted Lemon wrote:

> This isn't _quite_ true.   DNSSEC supports trust anchors at
> any point in the hierarchy, and indeed I think the right
>  model for DNSSEC is that you would install trust anchors
> for things you really care about, and manage them in the
> same way that you manage your root trust anchor.   E.g.,
> you'd install a trust anchor for your employer, and your
> bank, and maybe your local town government.   This is
>  all future UI work, of course.

Operationally, that's not practical. Users can't manage
their trust anchors securely.

> Furthermore, if the root key is compromised and that is then
> used to substitute a bogus key, it isn't that hard to notice
> that this has happened, and indeed we ought to be
> systematically noticing these things.   So hacking the root
> key is certainly a valid threat, but there is a great deal
> more transparency in the DNSSEC system than in the TLS PKI,
> and that should mean that the system is more robust in the
> face of this kind of attack.

According to your theory, we don't need DNSSEC, because
cache poisoning attacks on plain DNS is easily detectable.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 13 Sep 2013 06:02:59 +0900

> in NTP on the router and you are good to go.

Faking GPS signal is trivially easy.

Iraq successfully captured US unmanned plain, apparently by
supplying it false location.

						Masataka Ohta

---

From: David Morris <[email-masked]>
Date: Thu, 12 Sep 2013 22:11:15 -0700 (PDT)

> In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that

No, I mean that the Home class gateway device would not accept any
traffic for it's inside network until it has DNSSEC validation and
related NTP setup was completed. This would extend the apparent boot
time a small amount of time relative to other components of the boot
sequence. By not allowing thru traffic, I think the concern about
DNS results being cached on the inside network would be a non-issue.
And the gateway device controls its own cache so flushing it should
not be an issue

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Sep 2013 10:27:54 +0200

Ted,

What I like about this message is that you have demonstrated the
*potential* severability of these issues.  Things are set up as they are
for a matter of scaling.  Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity.  It's also pretty
clear that we should be reviewing this stuff in consultation with
ICANN's SSAC committee.

Eliot

---

From: Glen Wiley <[email-masked]>
Date: Fri, 13 Sep 2013 17:33:44 -0400

This discussion highlights the importance of making sure that hardware vendors understand the need for working clocks that can be easily bootstrapped.  In addition to NTP radio clock receivers are ubiquitous, tiny and ridiculously cheap.  It is unconscionable that any consumer electronics are sold today that boast a visible clock without including a radio clock receiver!  This doesn't fix the mountain of already deployed SOHO gear, but it is time for vendors that know better (Cisco, Netgear, D-Link, etc.) to do the right thing.

I put entropy in a similar class of problem as radio clock receivers.  There are a number of reasonable sources for entropy that take up virtually no PCB space and can be built with a few discrete components (thinking of quantum effects between 2 transistor gates or zener breakdown noise on a zener diode).  Stronger entropy sources get expensive - but something that provides reasonable entropy for light crypto should be available on SOHO class network gear.

On Sep 12, 2013, at 2:19 PM, robert bownes wrote:

> 
> Chiming in a bit late here, however, the availability of stratum 1 clocks and stratum 2 class time data on non IP and/or non interconnected networks is now so large, I question why one would run NTP outside of the building in many cases, certainly in an enterprise of any size.
> 
> A 1pulse per second aligned to GPS is good to a few ns. Fairly straightforward to plug into even a OpenWrt type of router. Turn on the pps in NTP on the router and you are good to go. 
> 
> 
> 
> 
>

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 14 Sep 2013 22:27:40 +0900

> registrar) would need to change the DNS server name/IP, and replace the DS

Only to a victim to be deceived.

> TLD authority (delegation) servers.

Wrong. The domain owners can't know some victims are supplied
faked data.

							Masataka Ohta

---

From: SM <[email-masked]>
Date: Sat, 14 Sep 2013 09:55:44 -0700

Hi Paul,
>>the NSA's Key "Recovery" Service.  Secondly, if the web site has all

http://www.youtube.com/watch?v=-qrlDGhoI1Q

>TCP - I'm hoping more people will put up TCP-only open resolvers,

RFC 5358 has a "SHOULD NOT" for open resolvers.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 14 Sep 2013 09:45:53 -0700

Hi Tony,
>to prevent other registrars from undermining that security.

There is a well-known domain for a well-known newspaper which had a 
problem at the registrar end.  It's doubtful whether the entity 
responsible for the well-known domain has assessed the threats correctly.

Regards,
-sm

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Sep 2013 14:22:32 -0400 (EDT)

> RFC 5358 has a "SHOULD NOT" for open resolvers.

Too bad RFC 5358 was written with an implicit UDP-only in mind. Perhaps
someone should file an ERRATA :)

Paul

---

From: Jim Gettys <[email-masked]>
Date: Tue, 17 Sep 2013 08:48:54 -0400

On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley <[email-masked]> wrote:

> This discussion highlights the importance of making sure that hardware
> vendors understand the need for working clocks that can be easily
> bootstrapped.  In addition to NTP radio clock receivers are ubiquitous,
> tiny and ridiculously cheap.  It is unconscionable that any consumer
> electronics are sold today that boast a visible clock without including a
> radio clock receiver!  This doesn't fix the mountain of already deployed
> SOHO gear, but it is time for vendors that know better (Cisco, Netgear,
> D-Link, etc.) to do the right thing.
>

Radio clock receivers often don't work where these devices are deployed
(like in my basement).  Not enough view of the sky (and multiple layers of
floors).  Radios are "nice to have", but can't be guaranteed to work.

>
> I put entropy in a similar class of problem as radio clock receivers.
>  There are a number of reasonable sources for entropy that take up
> virtually no PCB space and can be built with a few discrete components
> (thinking of quantum effects between 2 transistor gates or zener breakdown
> noise on a zener diode).  Stronger entropy sources get expensive - but
> something that provides reasonable entropy for light crypto should be
> available on SOHO class network gear.
>

Yes, and probably will be someday, and we should all encourage them to do
so.  I agree that SOC vendors should be encouraged to include such
generators (as but one of many sources of entropy: see the following
discussion:
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J ).

Doesn't help in the meanwhile....
                - Jim

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Sep 2013 14:40:17 +0900

> floors).  Radios are "nice to have", but can't be guaranteed to work.

No, the problem of radio clock is not its availability but that
they can easily be faked, which means it is no better than relying
on some NTP service, such as time.nist.gov, which is as
(un)trustworthy as USG.

						Masataka Ohta