Subject: [homenet] DNSSEC and homenet

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Mar 2014 21:00:21 +1100

The optimal place to sign DNS zones is where they are
	generated.  For homenet this is in the home.

	For zeroconf the CPE generates DNSKEY records and pushes
	DS records for them to the parent zone.  We know how to do
	this securely.

	If you replace a CPE it just pushed new DS records for the
	new DNSKEY records it generates.  This is equivalent to a
	emergency key rollover and only impacts client that have
	cached records for the zone or its DS records.

	For split horizon zones you use the same DNSKEYS in all
	versions of the zone.  This prevents issues with cached
	DS/DNSKEY records as machines move from being locally
	connected to externally connected.

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

---

From: Ralf Weber <[email-masked]>
Date: Tue, 4 Mar 2014 10:08:53 +0000

Moin!

> 	cached records for the zone or its DS records.
What if the new device doesn't support DNSSEC signing? I still think there are reasons to support both archictectures (signing on the CPE or on the ISP auth name server). I have no problem with signing on the CPE. I just don't want to make it mandatory, as I have seen more problems with CPEs than with ISP operations (ok I may be biased here working in ISP operations for 15 years ;-).

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Mar 2014 21:15:36 +1100

In message <[email-masked]>, Ralf Weber writes:
> What if the new device doesn't support DNSSEC signing? I still think
> there are reasons to support both archictectures (signing on the CPE or
> on the ISP auth name server). I have no problem with signing on the CPE.
> I just don't want to make it mandatory, as I have seen more problems with
> CPEs than with ISP operations (ok I may be biased here working in ISP
> operations for 15 years ;-).
>
> So long
> -Ralf

The CPE that doesn't sign clears the DS records rather than adding /
replacing the DS records.  The zones still need to be delegated.
If the CPE doesn't request deletations.  The ISP DHCP server clears
the delegation from its zones and that includes DS records.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 05:39:22 -0500

My three points that I made:

1) if the key resides in the CPE, then the ISP-owned CPE deployment
   is functionally identical to the Mark-Andrews/Michael-Richardson owned CPE
   deployment.
   => perhaps the underlying worry is that unless CPE-borne DNSSEC isn't
      the default/only-choice, that ISPs won't support it, and those of us that care
      will, again, be left in the cold.
      There is significant precedent that given a choice, ISP have made
      poor choices, and some of those choices have become architectural
      catatrophies.

   I agree with Mark: there is no issue with replacement of CPEs, etc.
   I don't think that I would move the private key from one CPE to another.
   For the reverse zone, just a new private key and populate that.
   For a forward zone that I owned, I would push a new DS record upwards.
   The likely reason for a new CPE is that the blue smoke got out of the old
   one.  If the models were compatible, and I had a backup of the config,
   then perhaps the private key would move, but that seems doubtful for most
   users.

2) what Andrew Sullivan said: if the keys are different for inside the home
   vs for outside the home, then any mobile node will get confused and/or
   will have to flush it's DNS cache way too often.

3) the perpass/National-Security-Letter situation.
   If the key by default resides at the ISP, then it is the ISP that gets
   served when some agency thinks it wants to divert traffic by changing DNS,
   and once served, the net may may be much larger than desired.
   By putting the key in the CPE, the legal papers will have to specify that
   device.  It may still be the ISP legal department that responds, but the
   chance of screwing up is larger.

   While it seems like the ISP might be better able to protect a single
   private key against various vulnerability; having more technical people
   than the average home user, etc... the impact of a compromise is so much
   larger.   Yes, home routers have vulnerabilities:  if we assume that they
   are breachable, then the breach can just change the unsigned data, having
   the private key at the ISP doesn't help us at all.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 05:45:47 -0500

> there are reasons to support both archictectures (signing on the CPE or

Then I think that it doesn't support DNS delegation anyway.

Ralf Weber <[email-masked]> wrote:
    > CPE. I just don't want to make it mandatory, as I have seen more
    > problems with CPEs than with ISP operations (ok I may be biased here
    > working in ISP operations for 15 years ;-).

I also have many years of experience in ISP operations as a consultant and owner.
ISPs make a lot of short-term decisions that bite them later on.
I observe a pendulum of picking the cheapest CPE device, followed by picking
an overkill CPE device (for their "managed" service). Lather, rinse, repeat.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Mar 2014 05:52:18 -0500

On Tue, Mar 04, 2014 at 10:08:53AM +0000, Ralf Weber wrote:

> or on the ISP auth name server). I have no problem with signing on
> the CPE. I just don't want to make it mandatory

For the purposes of this discussion, I'm going to assume that one has
an inward-facing zone and and outward-facing one (i.e. this is a
split-brain DNS situation).

Now, if the inward-facing DNS (wherever it's run -- CPE or elsewhere
in the homenet) signs anything, then you must have common keys for the
outward-facing DNS.  (I suppose as an alternative, you could use
extremely low TTLs on your zones -- say, a few minutes).  This is
because one of the use cases we originally had in mind was that you
carry your laptop off to some out-of-homenet network and want access
to services inside the homenet.

Since we're all wandering around with a DNS cache on our laptops any
more, you could easily get an answer back from (say) the homenet DNS
with the DNSKEY record.  You will cache it.

If you then go to some other network, you will try to validate with
that DNSKEY that you have cached (until it expires).  If you then
query for some resource inside the homenet for a record you don't
already have cached, you'll need to be able to validate it; so it
needs to be validatable using that same cached key record.  If it's
not, then the data will validate bogus and you'll fail to connect.

The same issue is true in the other direction. 

So if we're going to say that the signing may happen in the ISP's
infrastructure, then either (1) we need a mechanism to share private
keys (which sounds like a bozo move to me or (2) we need to state that
it is incompatible with using DNSSEC in the inward-facing zone or (3)
we need to state that any access to any DNSSEC-signed name in the
outward zone should be expected to route through the ISP link;
inside-homenet-only names may use in-homenet interfaces.  (I'm sure
there's a more elegant way to say that, but I've written in haste.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 06:41:51 -0500

> to services inside the homenet.

While it's a good use case example, a better one is that your smartphone
wanders on your person, inside your home, and then uses 3G for a few seconds
when you wander onto the porch, and the wifi signal goes to zero.

The important thing is that you didn't do anything to actually "leave" your
home, while the laptop situation is perhaps more intentional, and contains
many possible signals that a cache should be flushed.

    > with the DNSKEY record.  You will cache it.

The MIF people have some statements about flushing caches, and about caching
on a per-interface basis. (I think that this is all wrong, btw)

    > there's a more elegant way to say that, but I've written in haste.)

A fourth option is that the name from the outside is different than the name
From the inside.  I think that this is the least interesting version.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 04 Mar 2014 13:28:15 +0100

inline.

> split-brain DNS situation).

I think even large corporations are slowly learning that split-brain DNS 
is a bad idea that seemed like a good idea at the time, especially in 
the presence of highly-mobile devices, and forwarders.

I'm becoming a convert myself to that way of thinking. That doesn't mean 
to say that we can't use 'views' or some other mechanism to hide some 
records from being resolvable from the outside.

-- 
Regards,
RayH

---

From: SM <[email-masked]>
Date: Tue, 04 Mar 2014 04:50:33 -0800

Hi Andrew,
>not, then the data will validate bogus and you'll fail to connect.

That's an interesting case.  I did not think of it.  If I understood 
correctly the answer in the DNS cache would be for a non-global 
resource.  There is no longer an assumption of uniqueness.  As a 
local decision I would use low TTLs [1].

Regards,
-sm

1. I gave some thought to the state of connectivity in future.  I 
suspect that there would be edge cases.  I don't know whether it is 
worth discussing about those cases.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 08:30:35 -0500

> I think even large corporations are slowly learning that split-brain
    > DNS is a bad idea that seemed like a good idea at the time, especially
    > in the presence of highly-mobile devices, and forwarders.

    > I'm becoming a convert myself to that way of thinking. That doesn't
    > mean to say that we can't use 'views' or some other mechanism to hide
    > some records from being resolvable from the outside.

The issue is that actually, you want some nodes to be able to resolve many
records even when they are "outside".

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 13:51:51 +0000

>   then perhaps the private key would move, but that seems doubtful for most

How are you going to push DS records upwards if you have lost your key?

>   chance of screwing up is larger.

This is probably the best argument I've heard against putting the keys on the ISP's server.   However, you still have to make it work.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 01:02:13 +1100

> How are you going to push DS records upwards if you have lost your key?

If you have example.com then you are not zero conf and you add you tsig
key to the cpe.

If you are using a ISP assigned name then you re-establish credentials
as part of the DHCP exchange with the ISP.

Updating DS does not and should not require working DNSSEC to do however
this is a arguement for Friday and DNSOP.

> This is probably the best argument I've heard against putting the keys on the
>  ISP's server.   However, you still have to make it work.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 10:39:38 -0500

Ted Lemon <[email-masked]> wrote:
    >> The likely reason for a new CPE is that the blue smoke got out of the
    >> old one.  If the models were compatible, and I had a backup of the
    >> config, then perhaps the private key would move, but that seems
    >> doubtful for most users.

    > How are you going to push DS records upwards if you have lost your key?

Same way that I got my zone bootstrapped when I first bought it.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 15:44:29 +0000

> Same way that I got my zone bootstrapped when I first bought it.

When you bootstrapped it, you didn't already have a key established.   Now you do.   Is the ISP supposed to just trust you when you re-key your zone?  This seems like a nice attack surface.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 04 Mar 2014 16:52:54 +0100

> Michael Richardson <mailto:[email-masked]>
> 4 March 2014 14:30
Agreed. Cloud computing being a prime disruptor to the split brain model.

-- 
Regards,
RayH

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 11:59:10 -0500

> When you bootstrapped it, you didn't already have a key established.
    > Now you do.  Is the ISP supposed to just trust you when you re-key your
    > zone?  This seems like a nice attack surface.

As Mark said, if it's an ISP provided zone, then pushing the new DS is done
under the TSIG key that the DHCP established. (So, ted-lemon-house.isp.example.net,
and the reverse map).

If it's fugue.com, then you have to go to your registrar and change DS.
This is largely akin to what you'd do if your key was compromised.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 17:05:59 +0000

> under the TSIG key that the DHCP established. (So, ted-lemon-house.isp.example.net,

Oh, so the TSIG key sent in the clear over DHCP is the attack surface.   Got it.   Actually during the DHC working group presentation, we asked Daniel to take the TSIG key out because it's not secure.   The right way to do it is with SIG(0).   But that doesn't provide a way to repudiate a lost key, because it relies on a leap of faith to begin trusting the initial key.

If the connection between the DHCP server and DHCP client is secure, then a nonce sent over DHCP could be used along with SIG(0) to assist, but this is not the only potential configuration.   Trusting the wire works pretty well in these scenarios in practice, but only if there _is_ a wire.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 04:58:12 +1100

In message <[email-masked]>, Ted Lemon writes:
> Oh, so the TSIG key sent in the clear over DHCP is the attack surface.   Got 
> it.   Actually during the DHC working group presentation, we asked Daniel to 
> take the TSIG key out because it's not secure.   The right way to do it is wi
> th SIG(0).   But that doesn't provide a way to repudiate a lost key, because 
> it relies on a leap of faith to begin trusting the initial key.
> 
> If the connection between the DHCP server and DHCP client is secure, then a n
> once sent over DHCP could be used along with SIG(0) to assist, but this is no
> t the only potential configuration.   Trusting the wire works pretty well in 
> these scenarios in practice, but only if there _is_ a wire.

Please go read draft-andrews-dnsop-pd-reverse.  This technique will
work with any zone to be delegated by the ISP.  For most cases the
wire is the authenticator by for things like WiMax you will be
putting credentials into the box to authenticticate your DHCP request
to the ISP as the medium is not secure anyway.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Mar 2014 18:08:22 +0000

> to the ISP as the medium is not secure anyway.

Your draft is certainly a valid solution to the problem it sets out to solve, but it doesn't actually change the security model I was talking about.   Given that my point was that you have to trust the wire to make this work, I think are in violent agreement at least on this point, except that I would like us to describe a solution that at least addresses the use case where you can't trust the wire.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 05:17:42 +1100

In message <[email-masked]>, Ted Lemon writes:
> Your draft is certainly a valid solution to the problem it sets out to =
> solve, but it doesn't actually change the security model I was talking =
> about.   Given that my point was that you have to trust the wire to make =
> this work, I think are in violent agreement at least on this point, =
> except that I would like us to describe a solution that at least =
> addresses the use case where you can't trust the wire.
 
A HMAC-* option for DHCP (c.f. TSIG) would work if we have to
authenticate a DHCP request without relying on any other layers.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 13:33:21 -0500

Ted Lemon <[email-masked]> wrote:
    >> As Mark said, if it's an ISP provided zone, then pushing the new DS is
    >> done under the TSIG key that the DHCP established. (So,
    >> ted-lemon-house.isp.example.net, and the reverse map).

    > Oh, so the TSIG key sent in the clear over DHCP is the attack surface.

Yes, I agree, that is the attack surface!

Using SIG(0) with leap of faith is certainly a better thing, and I agree with
you that this then makes the "blue-smoke-got-out-of-CPE" problem more
difficult.   I think that I now forget what other situations we have that
caused us to replace the CPE.

1) The leap-of-faith could be reset by the ISP when they also send out the new
   router.

2) The new CPE might send a different DUID in DHCPv6, and this might cause the ISP
   to allocate a new prefix to you.  This clears the leap-of-faith for the
   reverse zone.
   (please forgive me if DUID was the wrong term. I think I'm right here)

3) if this was really PPPoE, then the "link", while still in the clear,
   was authenticated at "layer-2" from your PPPoE username/password, and
   maybe something could be leveraged there to reset "ted-lemon-house.isp.example.net".
   For the WiMax with authenticated ESSID, there may be a similar layer-2
   signal.  I agree that this likely doesn't work ("trusts wire") for the
   generic ethernet-like [cable/GPON/FTTH] cases.

    > Got it.  Actually during the DHC working group presentation, we asked
    > Daniel to take the TSIG key out because it's not secure.  The right way
    > to do it is with SIG(0).  But that doesn't provide a way to repudiate a
    > lost key, because it relies on a leap of faith to begin trusting the
    > initial key.

    > If the connection between the DHCP server and DHCP client is secure,
    > then a nonce sent over DHCP could be used along with SIG(0) to assist,
    > but this is not the only potential configuration.  Trusting the wire
    > works pretty well in these scenarios in practice, but only if there
    > _is_ a wire.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Mar 2014 18:42:06 -0500

> local decision I would use low TTLs [1].

But as Michael pointed out upthread, the more realistic and compelling
(if harder to understand) examples involve a dual-homed node like a
phone flipping from one interface to another.  You'd need sub-second
TTLs for that not to be a problem, and we don't have those.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 16:12:21 +1100

> TTLs for that not to be a problem, and we don't have those.

I don't see current phones flip from WiFi to 3/4G multiple times a
second.  They have longer duty cycles than that.  Additionally if
you are in such a zone you tend to 1) move or 2) force WiFi or 3/4G
to get stability.

Additionally the impact of getting the wrong version is that you end
up with a unusable address when you get a ULA/RFC 1918 address packets
to which should be dropped by the telco or you get NXDOMAIN or the
global address of the resourse and hair pinnig in the NAT helps with
the later.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Mar 2014 04:15:38 -0500

Mark Andrews <[email-masked]> wrote:
    >> On Tue, Mar 04, 2014 at 04:50:33AM -0800, SM wrote: > correctly the
    >> answer in the DNS cache would be for a non-global > resource.  There
    >> is no longer an assumption of uniqueness.  As a > local decision I
    >> would use low TTLs [1].
    >>

    > second.  They have longer duty cycles than that.  Additionally if you
    > are in such a zone you tend to 1) move or 2) force WiFi or 3/4G to get
    > stability.

Current Android phones have to turn one or to turn the other on. (I can't
speak for other brands).  They also don't do MIF at all.
That why it takes so long, and it pissed people off, and it's gonna get fixed.

At that point, it won't be that they "flip", so much as they always have the
3G alive, but the wifi could get too weak and it might flip things over.

People don't want to be "forcing" things --- they want to just have a device
in their pocket that does stuff for them.

So I agree that this isn't a problem we see today, but maybe next year;
certainly before homenet w/DNSSEC is seen by early adopters.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 20:58:23 +1100

In message <[email-masked]>, Michael Richardson writes:
> --=-=-=

iPhones flip based on WiFi signal strength and being to associate with the
AP but certainly not multiple times a second.

> in their pocket that does stuff for them.

Which they do today.  If you are sitting on the edge of WiFi range you get
a bit of flip flop but most of the time one is just "On WiFi" at home or
on 3G (or whatever) when away from home.

For me the WiFi border is sitting at the bus stop around the corner.
 
> certainly before homenet w/DNSSEC is seen by early adopters.

I really don't see this as being a issue in practice.  Just sign
the zone (all verisons) in the house with the same keys.  Stop with
this nonsence idea that you shouldn't sign the internal version
when you are signing the external version.

The CPE is a recursive server on the inside interfaces that is also
authoritative for these zones with acls limiting recursion to
internal addresses.  The external interface is only authoritative
for the external version of the zones.

For the record I have split horizon signed zones with the same
DNSKEY records for both versions running on my border router which
is a 1998 vintage PC and have done for about a decade now.  Same
sort of compute power and storage as you can get in modern CPE
devices.  I eat my own dog food.  The nameserver accepts dynamic
updates from both the DHCP server and internal clients.  The home
has GUA, ULA IPv6 addresses + RFC 1918 addresses for IPv4.  This all
just works.

Mark

> --=-=-=
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQCVAwUBUxbrOYqHRg3pndX9AQKlxgP+LCknfzxYHrCaqI+MrC8Y8BEEsT7U2/2j
> VL2iVIw6udK9VKoe+50EPMIFs8R9o5le+Nsy2DVuY4uDj6u5Ys0GDZ6Lbys5WMAC
> m0YX/CVxYodH5fqN3DD+tKqPoGIPe1xtAimjs03r/plly8YiLjh/bDs7PRkL9Aqk
> 0QbA2WuKKzI=
> =U60b
> -----END PGP SIGNATURE-----
> --=-=-=--

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Mar 2014 05:25:37 -0500

Mark,

> a bit of flip flop but most of the time one is just "On WiFi" at home or

The point is that we're designing a protocol, and "most of the time"
won't be good enough to avoid support calls to the ISP help desk.  ISP
margins are thin enough that it would be a bad thing to build a
specification that encourages that even rarely.

> when you are signing the external version.

Mark, you're at least jumping ahead to implementation and at worst
begging the question.  We started with a proposal that did signing in
the ISP's server.  I was pointing out the consequences of that for
DNSSEC.  One of the possible solutions is that the "internal version"
is unsigned.  It would be careless not to list that as one of the
possibilities, even if I think that's a foolish outcome.  We have to
list the possibilities we don't like, too, or else we won't have a
clear picture of what we're talking about.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2014 22:01:59 +1100

> specification that encourages that even rarely.

This is a problem that is INDEPENDENT of DNSSEC when you are siging both
zones.   This is about there being two versions of the zone.

> clear picture of what we're talking about.

Signed and unsigned versions of the same zones are a REALLY REALLY
REALLY REALLY bad idea.  This is a "Doctor it hurts if I do this.
Then don't do this." example. It could be made to work with negative
trust anchors which are installed when the WiFi SSID matches the
home's SSID but we really don't want to go there.  There be dragons.

It is dead simple for nameserver in the CPE to do the signing.  Why
people thing it is beyond the capabilities of the a device like
this is beyond me.  The CPE generated the keys.  It signs the
records.  It updates the parent zone to add DS records for the keys
it has generated.

The owner of the CPE has to do nothing to make this happen.

Either sign all version or don't sign any.

I will appeal any version that even hints that mixed signing is the
way to go.  It is just bad design, bad engineer and will cause pain
for everyone.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Mar 2014 06:15:31 -0500

Mark Andrews <[email-masked]> wrote:
    >> People don't want to be "forcing" things --- they want to just have a
    >> device in their pocket that does stuff for them.

    > Which they do today.  If you are sitting on the edge of WiFi range you
    > get a bit of flip flop but most of the time one is just "On WiFi" at
    > home or on 3G (or whatever) when away from home.

Well, it takes so long that it's really annoying, and I know that being on
both networks at the same time ("make before break") is where things are going.

    > For me the WiFi border is sitting at the bus stop around the corner.

The wifi in my front yard depends upon whether the front door is open or
closed.

    >> So I agree that this isn't a problem we see today, but maybe next
    >> year; certainly before homenet w/DNSSEC is seen by early adopters.

    > I really don't see this as being a issue in practice.  Just sign the
    > zone (all verisons) in the house with the same keys.  Stop with this
    > nonsence idea that you shouldn't sign the internal version when you are
    > signing the external version.

We are in violent agreement here: it seems like you are arguing with my use case.
I agree with you: signing with the house key solves the problem of devices
wandering.

    > For the record I have split horizon signed zones with the same DNSKEY
    > records for both versions running on my border router which is a 1998
    > vintage PC and have done for about a decade now.  Same sort of compute
    > power and storage as you can get in modern CPE devices.  I eat my own
    > dog food.  The nameserver accepts dynamic updates from both the DHCP
    > server and internal clients.  The home has GUA, ULA IPv6 addresses +
    > RFC 1918 addresses for IPv4.  This all just works.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 5 Mar 2014 11:22:27 +0000

> home's SSID but we really don't want to go there.  There be dragons.

I think the fundamental question is 
"Do we expect that INTERNAL zones on a home-net are signed ?

If the answer is yes then we have to assume that some device are DNS servers have the 
ability to sign the zones. If they can sign the internal zones they can sign the
external zones. 

The key management when devices are "rolled" is an issue but that can be addressed 
by smart use of storage devices. 
Rolled here means both Re-flashed and replaced by new one

> records.  It updates the parent zone to add DS records for the keys

The device can sign if it has accurate time, 
it can generate keys if it has good source of randomness. 
It can be relied upon if the zone survives reboots. 

> The owner of the CPE has to do nothing to make this happen.

There is no harm in signing when there is no DS 
it is real bad to sign with a new key when there is a DS in place, 
the same goes for not signing when there is a DS but the errors will be different, 

If the ISP/third party is signing the zones then they can handle the DS management and it is easier to 
roll the devices. 

> way to go.  It is just bad design, bad engineer and will cause pain

The question is what is the "least bad design the can be deployed" along with the question
"is there one fits all solution?" 

	Olafur

---

From: Ray Hunter <[email-masked]>
Date: Wed, 05 Mar 2014 12:57:58 +0100

Mark Andrews wrote:
> In message<[email-masked]>, Andrew Sullivan writes:
>> Mark,
>>
> REALLY REALLY bad idea.
+1
>   This is a "Doctor it hurts if I do this.
+1

-- 
Regards,
RayH