Re: [DNSOP] pushing updates to the parent

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Paul Wouters w
rites:
> On Sat, 8 Mar 2014, Mark Andrews wrote:
> 
> > Our audience should be the CPE developer with the one "turn on
> > DNSSEC" button which generates the keys, signs the zone, pushes
> > keys upstream at the right time.  It has a username/password field
> > for zones where it is not automatically installing KEY records as
> > part of the automatic delegation process.
> 
> Buy router. Configure DNS. CPE uploads DS record.
> 
> I forget my password, factory default the firmware, configure DNS,
> attempt to upload a new DS record.
> 
> Either:
> 
> a) authentication fails and my domain remains broken
> b) it works, meaning any CPE compromise will lead to massive DNSSEC
>     circumvention.

And if you have forgotten you password and use DNS scrapping you are
also hosed.  The CPE doesn't have the old DNSKEYs to sign the data
and if you have forgotten the password you are hosed.

In reality both methods have the same failure modes.  Both bootstrap
from the web.  Both require going back to the web to recover from
a CPE change.  The only exception in the case where you are getting
delegations from the ISP for PD and homenet forward zone which use
SIG(0) and public keys trasmitted as part of the DHCP process.

> Neither are desirable, and why people wanted the update systems to be
> bootstrapped externally and did not want to allow the update mechanism
> to change the security status of zones.

And that is applying business logic to the update request.  Nothing
in my draft prevents the Registrar rejecting the change.

> > The second audience is the DNSSEC Key management tool developer which
> > has a policy file which says "roll the key for this zone monthly/yearly"
> > and just ensures it happens.
> 
> This works with any of the proposals, once you boostrap via EPP. I don't
> know many people who want to bypass the bootstrap.
> 
> > nsupdate is how one does it today because the other bits of software
> > that will use the method have not yet been written because we (the
> > IETF) haven't provided them with a full standardised solution which
> > works everywhere.
> 
> I think we have. But registrars don't provide a unified method for
> updating that information to _their_ customers. They could easilly
> setup their own EPP channel to talk to their registrants and avoid
> using custom website GUIs. Some, like gkg.net, provide nice and simple
> JSON API's, but the location and format is not standarised (but could
> easilly be if registrars want that). ICANN did well in enforcing the
> location for registrant facing services like WHOIS for the new GTLDs.
> Perhaps it can extend this for other registrant-facing services like
> DS update. Using EPP here would make a lot of sense.

They could do that but they have not.
 
> > nsupdate is the proof of concept tool.  It is the fill the gap tool
> > until the others are written.  It is the fix it tool.
> 
> nsupdate can never fix the bootstrap. The initial authorization that
> allows signed zone content to be trusted by the registrar to make
> domain registry modifications but involve a human.

Which is why the update request is signed.  You sign into a web
page.  You sign the request set via UPDATE.  Both are equally secure.

For web scrapping you have to sign into the web to upload the DS
records.

For this you have to sign the update using credentials shared with
the parent (TSIG or SIG(0)).

Both have bootstrap steps.  One however only works with signed zones
the other works with all types of zones.

> > However in all cases we have RRR and non-RRR managed zone and the tools
> > need to work with all of them.
> 
> The initial bootstrap problem is the same for RRR and non-RRR, unless
> parent and child are under teh same administratiev control, in which
> case it should already be handled. (A previous DNS signer product I
> worked on fully automated rollovers if parent and child were managed
> by it)
> 
> > We also have nameservers that are being renumbered that need to
> > push new glue records for themselves to the parent zones.  This
> > will happen with both signed and unsigned zones and their is no
> > "scraping" solution that works for this senario.
> 
> You still need an authorization step there for the RRR case. I believe,
> and I think the WG concensus was the same, that the best way for that
> authorization step was to use out of band EPP using the KSK. In other
> words, once you get the KSK at the registrar, you can use signed records
> within your zone for signaling without requiring another set of credentials.

Which means it only works for dnssec signed zones.  I would love it if
every zone was signed but when you are defining a update process that
doesn't work for 90+% of current zones you are missing the mark.

This is not just about DS updates.  It is about A, AAAA and NS updates.
It about having those work for signed and unsigned zones.
 
> nsupdate requires a new set of credentials, as well as a new API as to
> where to send the nsupdate to, possibly with new firewall holes. It
> requires dynamic zones or custom software pretending to run dynamic
> zones to take the update. The domain owner would need to keep another
> secret on their "live nsupdate machine" apart from the private KSK key.

Which is a whole load do FUD.
 
> Using zone data for signaling also works for the non-RRR use cases.
> 
> These were all reasons for the WG to agree on signed zone content as
> an authorization method for parent updates.
> 
> Paul

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]