Subject: [DNSOP] CPE devices doing DNSSEC

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Mar 2014 21:05:24 +1100

What do we expect CPE devices to implement to update parent
	zones.  100 different things to cover all the update methods
	registrar's come up with.  Or do we say do exactly one
	method that works in all situations?

	We already have a problem today were they can't do dynamic
	update to every dynamic dns provider because they implement
	non standard adhoc methods rather that one standardised
	method.

	I know Registrars don't like to be told what to do but this
	is a case where interop from 100's of CPE providers and
	1000000's of parent zones made up of RRR zones and non RRR zones
	needs to work reliably without lots of choice.

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

---

From: Joe Abley <[email-masked]>
Date: Fri, 7 Mar 2014 10:21:34 +0000

> 	non standard adhoc methods rather that one standardised

https://xkcd.com/927/

Joe

---

From: Tony Finch <[email-masked]>
Date: Fri, 7 Mar 2014 10:49:50 +0000

> https://xkcd.com/927/

So from the standards development point of view, I think what this is
saying is that success is more likely to come from building on what people
are already doing and nudging more of them to do it more similarly.

The problem with the parent update process is that there's a hopeless zoo
of more-or-less crappy APIs almost none of which are good foundations.

For a push-style protocol there are two parts: finding out where to push
the update; and how to push the update.

The where question ought to be answered by whois or weirds or _update SRV
records.

The how question ought to be answered by EPP (from registrant to
registrar) or DNS UPDATE. It would be nice if there were software to
gateway between one and the other.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Southwest 6 to gale 8, becoming variable 4, then southeast 5 later.
Slight or moderate. Rain, becoming fair. Moderate becoming good.

---

From: Joe Abley <[email-masked]>
Date: Fri, 7 Mar 2014 15:39:37 +0000

> are already doing and nudging more of them to do it more similarly.

Sure, maybe.

I think we have to consider our target audience. Part of that is to consider the existing menagerie and understanding the shape of the expected solutions space.

While we in this group might find comfort in arcane binary protocols using UDP port 53, the habits of people who frequent the dyndns zoo seem to be far more tilted towards throwing JSON documents around over HTTP. It's hard to imagine unifying a pile of RESTish APIs with something that looks foreign and different.

I'll +1 Andrew and say that I have my doubts (a) that the underscore scaffolding will ever appear in the top-most labels and (b) that anybody would use them if they did.

My poorly-informed doubt is hardly a reason not to document the idea. But I think it's a stretch to expect anything more than an XKCD-927 result.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Mar 2014 17:45:05 +0000

On Mar 7, 2014, at 10:05 AM, Mark Andrews <[email-masked]> wrote:

> 	I know Registrars don't like to be told what to do

+1

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Mar 2014 16:53:48 +1100

In message <[email-masked]>, Joe Abley writes
:
> I think we have to consider our target audience. Part of that is to
> consider the existing menagerie and understanding the shape of the
> expected solutions space.
>
> While we in this group might find comfort in arcane binary protocols
> using UDP port 53, the habits of people who frequent the dyndns zoo seem
> to be far more tilted towards throwing JSON documents around over HTTP.
> It's hard to imagine unifying a pile of RESTish APIs with something that
> looks foreign and different.
>
> I'll +1 Andrew and say that I have my doubts (a) that the underscore
> scaffolding will ever appear in the top-most labels and (b) that anybody
> would use them if they did.
>
> My poorly-informed doubt is hardly a reason not to document the idea. But
> I think it's a stretch to expect anything more than an XKCD-927 result.
>
>
> Joe

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.

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.

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.

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.

However in all cases we have RRR and non-RRR managed zone and the tools
need to work with all of them.

There are lots of tools today which use nsupdate as the backend to
update the DNS after putting addresses into a IPAM.

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.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Mar 2014 20:00:09 +1100

In message <[email-masked]>, Paul Hoffm
> > 	I know Registrars don't like to be told what to do

But they get told to do EPP to talk to the registries.

They have failed to invent / document a common standard way for
machine updates to work.  They could have quite easily got together
anytime in the last decade and done a standardised update protocol.

But they haven't.  We working in behalf of their customers who are
our customers have to work out a machine-to-machine protocol which
will do the job.  I have customers saying make "DNSSEC simpler".
One of the ways to make it simpler is to automate the updating of
records in the parent zone / parent registry.  We already have a
mechanism to do this for a plain parent zone.

We also have customers that are going to have machines that are not
CPE devices renumbered because ISP's will not guarentee stable
addresses with PD.  This leads to the requirement that one needs
to update glue addresses.  We already have a mechanism to do this
when they parent is a plain nameserver.

It's easy enough to translate

	delete-type
	add 
	add

to JASON

{
	"name" : "example.net",
	"DS" : [
		{
			"rdata" : "...."
		},
		{
			"rdata" : "...."
		}
	]
}

(yes a better jason schema that this is needed but again that is
something that need to be standardised.)

If one says "always send 'delete type' followed by all the records
that should exist" which is the type of UPDATE operations I would
recommend being done by these tools.  The tool could even enforce
it.  It's also easy to translate from Jason to UPDATE.

Mark

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Mar 2014 06:14:17 -0500 (EST)

> 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.

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 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.

> IETF) haven't provided them with a full standardised solution which

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.

> 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.

> 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)

> "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.

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.

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

---

From: Jim Reid <[email-masked]>
Date: Sat, 8 Mar 2014 11:47:22 +0000

> But they get told to do EPP to talk to the registries.

Correction: some registrars are obliged to use EPP to talk to some registries.

The followup to that is all TLD registries are exactly the same. Except where they are different.

Even in ICANN gTLD-land where everything's supposedly only done with EPP, low-volume registrars tend to use a web GUI rather than bother with an EPP client. The web back-end speaks EPP for them.

That said, even if this WG can come up with a standard for CPE to upload DS records or whatever -- good luck with that -- I am sceptical it will get widespread acceptance or deployment. Just look at the DNS brokenness that's in existing CPE firmware. The vendors simply don't care. They won't care until their customers, the ISPs, make them. An RFC might help. Though let's be realistic in our expectations.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 09 Mar 2014 08:28:39 +0000

On 2014-03-08 09:00, Mark Andrews wrote:
> But they haven't.

As long as the registries have _NOT_ unified their extensions of
whatever fluffy things they want, so that I as a registrar _really_ can
use the same EPP implementation to more than one (backend) registry,
then registrars have to spend energy and real $$ to implement those
incompatibilities. And do not have so much interest at all to do more
than many an API that is specific for them that faces the registrant.

We have been through this hundreds of times before and I think the
blaming _registrars_ as the ones that have an incompatible portion of
the system must stop.

Now.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 09 Mar 2014 08:30:31 +0000

> Correction: some registrars are obliged to use EPP to talk to some registries.

Correction: epp is not one protocol. It is one protocol profile per
backend registry.

A big failure for IETF I must say.

The architecture is broken, but, luckily IETF has now thanks to many
people started to work on this issue.

   Patrik

---

From: Patrik Wallstrom <[email-masked]>
Date: Sun, 9 Mar 2014 11:19:07 +0100

> blaming _registrars_ as the ones that have an incompatible portion of

But the fact is that EPP is several magnitudes better harmonized between TLDs compared to that registrars are offering their customers. There is no way around that today, and the registrars have no incentive at all to improve the situation. For all the registrars to offer the same API to their customers would really remove the lock-in effect that the proprietary interfaces that they have today.

So how could we change this? I don’t see this happening from a standard organization at all. So yes - registrars is really a big reason for incompatibility. Registries could easily bypass the current rrr model by exposing API:s directly to registrants, but it wouldn’t be very popular with the registrars…

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 09 Mar 2014 12:19:25 +0000

On 2014-03-09 10:19, Patrik Wallstrom wrote:
> But the fact is that EPP is several magnitudes better harmonized
> between TLDs compared to that registrars are offering their
> customers. There is no way around that today, and the registrars have
> no incentive at all to improve the situation. For all the registrars
> to offer the same API to their customers would really remove the
> lock-in effect that the proprietary interfaces that they have today.

The same lock-in as registries use already today with registrars.

My point is that there is absolutely no difference between how
registries lock in registrars (and because of that the registrants) and
how the registrars lock in customers.

Harmonizing the interface to registrars is _extremely_hard_ given how
different the epp implementation is for the registries. The registrars
that "lock in" (using your terminology) the registrants do that mainly
because they support a specific flavor of registries, and have designed
their API for those registries. If other registries where to be
supported, the API would be different.

> So how could we change this? I don’t see this happening from a
> standard organization at all. So yes - registrars is really a big
> reason for incompatibility. Registries could easily bypass the
> current rrr model by exposing API:s directly to registrants, but it
> wouldn’t be very popular with the registrars…

In no particular order:

1. By having people stop claiming epp is one protocol and blaming the
registrars being the problem. Pointing fingers does not help, because as
in this thread, energy has to be spent on explaining the differences in
epp between TLDs.

2. By having registries agreeing on whether DS or DNSKEY is the data
they want, or by accepting both.

3. By having the IETF effort of to start with cataloging the epp
extensions used by registries, and secondly working hard to try to
harmonize the extensions.

4. By having the registrars that have an API harmonize their efforts
just like registries harmonize theirs.

Also: note that registries do sent the wholesale price for the domain
registration, and the price on the market today for domain names is set
by the ones that cross subsidize domain name costs with income from
other services. Because of that there is a price squeeze which in some
markets turn into negative revenue for registrars that sell domain
names. Registries that now and then dump the wholesale prices does not
make the situation better, as the end users start to believe the price
is very low. Registrars complain on this behavior by registries, but the
registries continue to do price dumping -- i.e. continue the price squeeze.

Given this pricing structure, and that registries do change their
implementations far too often, where do you think registrars do spend
the money they have? They MUST support what the changes the registries
do, they do not HAVE TO implement a common API.

So, the registries MUST be the ones that start. Although there are many
registrars that will follow. Including Frobbit that I am technical lead at.

Now as I wrote above, IETF have started some very good work on epp
extensions but I am amazed how many registries refuse to participate,
complain, and fight against it. As long as they do, why should
registrars be nice(r)?

The market is broken, and as I said, I think we in IETF (when I was Area
Director btw) where too nice when the whole epp work took place.

   Patrik

---

From: Patrik Wallstrom <[email-masked]>
Date: Sun, 9 Mar 2014 13:55:55 +0100

> The same lock-in as registries use already today with registrars.

No, it is not the same lock-in.

> how the registrars lock in customers.

Yes, there is. Let me explain how.

Registries are using variants of the same protocol, EPP. Registries are typically serving exactly one name space. And this is where the lock-in  for the registrar come in - there are no other registries that serve the same name space.

Registrars are not using the same protocol, if any, as anybody else at all. They typically serve multiple name spaces. The large registrars have most of the name spaces available.

> supported, the API would be different.

I totally agree with your description of the registrars interface, and this was my main point.

Since I have looked in more detail on many registrar interfaces, they typically do not resemble each other in any way at all. They all serve different purposes.

1. Manage domains (register or delete domains).
2. Manage wallets (to see their invoices, refill accounts).
3. Update zone content (unusual).
4. Manage web sites.
5. Manage web site content.
6. Manage virtual private servers (VPS).
7. Update DNSSEC material (extremely unusual).

These are also all mixed up, so there is no interface that covers all of it, some choose only one or two of the things in the list, with any combination they choose.

The API:s are also implemented in a variety of flavours as well, XMP-RPC, REST, SOAP and whatever they can come up with.

This also makes it extremely difficult (on a whole other level compared to registrars talking to registries) for a registrant to move their automated interaction with one registrar to another registrar.

> in this thread, energy has to be spent on explaining the differences in

Yes. Nobody is pointing any fingers here. And this is all good work.

> they want, or by accepting both.

It seems that this is not going to happen.

> harmonize the extensions.

This is what the eppext wg is doing now.

> just like registries harmonize theirs.

Have you, as a registrar, put any effort into this? Where do you suggest this work is going to take place?

An “interesting" idea would be having ICANN to implement the base of this as part of the RAA.

> do, they do not HAVE TO implement a common API.

Well, registries have made registrars do DNSSEC before. So if we would actually try to describe a standardised interface for the registrars, there could be ways to make the registrars implement this new interface. Pressure from customers, registrars and ICANN combined, perhaps?

> Director btw) where too nice when the whole epp work took place.

There are way more problems for a registrar to implement EPP for the different registries than the extensions. You know that as well.

Registries have different policies regarding what names are allowed, how different objects are actually used, and different ways of handling expired domains. And this is already within the defined standard without any extensions.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 09 Mar 2014 13:18:31 +0000

> Registrars are not using the same protocol, if any, as anybody else at all. They typically serve multiple name spaces. The large registrars have most of the name spaces available.

No Patrik. The difference is so large between registries that there is
not much money to save between implementations of epp to different
registries.

> This also makes it extremely difficult (on a whole other level compared to registrars talking to registries) for a registrant to move their automated interaction with one registrar to another regis…

To me this looks very similar to what registries do.

Compare .DK, .EU, .SE and .ORG for example.

> Yes. Nobody is pointing any fingers here. And this is all good work.

I do not agree, there is a large portion of finger pointing going on.

> It seems that this is not going to happen.

Then you will not see a harmonized interface to registrars either.

> This is what the eppext wg is doing now.

Correct.

> Have you, as a registrar, put any effort into this? Where do you suggest this work is going to take place?

Oh yes. There are a number of things that must happen first, but one big
obstacle is that different registrars concentrate on certain registries,
like Frobbit concentrating on .SE. The interface to other registries is
so different that registrars that concentrate on other registries will
by definition have a different API.

Now, whether you think two REST API's with different semantics for
different registrars is better than what we have today, that is up to you.

> An “interesting" idea would be having ICANN to implement the base of this as part of the RAA.

No, that will not help. ccTLDs must be part of the story.

And the RAA is broken anyways, as it for example violates the regulation
and laws of the European Union, so they need to be cleaned up before for
example you can have _any_ ICANN Accredited Registrar from the European
Union (at least most member states -- it depends a bit on how they have
implemented the data protection directive).

I think CENTR, LACTLD, APTLD etc is the right forum.

> Well, registries have made registrars do DNSSEC before. So if we would actually try to describe a standardised interface for the registrars, there could be ways to make the registrars implement thi…

Once again, as long as registries do NOT have the same interface for
DNSSEC from registrars, how would registries be able to force the
registrars implement the SAME interface for DNSSEC to registrants?

> There are way more problems for a registrar to implement EPP for the different registries than the extensions. You know that as well.

Possibly if you strictly talk about the extension(s).

> Registries have different policies regarding what names are allowed, how different objects are actually used, and different ways of handling expired domains. And this is already within the defined…

Correct. And those differences are problematic. As well.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 09 Mar 2014 13:20:18 +0000

> Well, registries have made registrars do DNSSEC before. So if we would actually try to describe a standardised interface for the registrars, there could be ways to make the registrars implement thi…

I did btw notice you did not comment on the price squeeze issue. That is
_very_ serious as at the end of the day someone have to pay for the
developer writing the code.

Registries dumping wholesale prices must stop doing that.

   Patrik

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 09 Mar 2014 14:27:37 +0100

> anytime in the last decade and done a standardised update protocol.

But they have no incentive to do it!
No financial incentive anyway.

Registries have incentives to use EPP because it makes registrars' life
easier hence more registrars hence more channels for each registry hence
more domain names sold. Same setup for registrars: more registries using
EPP means less additional work each time they have to integrate one new
registry.

On the contrary, it is rare to have customers using more than one
registrars for all of their domain name assets. Hence, registrants build
specific tools to discuss with their registrars and life is good…  of
course until they need to switch to another provider.

Registries have the same problem on a border case problem (which may be
addressed with the eppext working group): they have no incentive to
standardize their own EPP extensions, and the parts that are needed in
the same way among multiple registries.

So, in short, I suspect we should not criticize nor wait for registrars
to build such standardized protocol because for them currently this
would be only additional work with no benefit what so ever (those
needing it already have some kind of local API).
Put it differently, it will work if some incentives are found, be it
contractual or otherwise.

I'm speaking as a former registrar dev having to handle multiple
registries at the RRP time with EPP not already dry when registries
tried to use it, and as a developer of an abstract API over registrars
API which gets no traction, for the obvious reason outlined above.

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 09 Mar 2014 14:36:27 +0100

Le dimanche 09 mars 2014 à 08:28 +0000, Patrik Fältström a écrit :
> incompatibilities.

These are not incompatibilities. It is by design, sort of.

While I can agree with you on many aspects of the sad current state of
EPP (having both implemented multiple client/server EPP stuff, and
having done presentations on EPP in various venues), the fact is that
trying to achieve 100% uniformity will never happen.

Registries, and specifically ccTLD registries, have distinct local
rules. They will never be exactly the same. You can find many voices
claiming that the current new batch of gTLDs make them all the same
because ICANN forces so many technical details in contractual terms.
Those voices see that as a downside, reducing differences means reducing
interest and differentiation biases.

It would be great if registries standardized parts that are needed the
same way in more than one of them, for example the case of change of
registrant ("trade").

Speaking for my own choir, having an EPP implementation able to speak
with 60+ TLDs shows that you _can_ have the same piece of code talking
into account the differences, which of course you need to hide in some
level of indirection (standard law of computer science).

There will always be some differences. Trying to squeeze them will not
work. Trying to find redundant extensions and merge them may work but
not without a lot of (non technical) work. Convincing registries to
document their EPP extension and even publish them as ID or RFC would be
great but not a simple task. We will see how EPPEXT goes along.

-- 
Patrick Mevzek

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Mar 2014 22:52:46 +1100

In message <[email-masked]>, Paul Wouters w
> b) it works, meaning any CPE compromise will lead to massive DNSSEC

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.

> 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.

> DS update. Using EPP here would make a lot of sense.

They could do that but they have not.
 
> 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.

> 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.
 
> secret on their "live nsupdate machine" apart from the private KSK key.

Which is a whole load do FUD.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Mar 2014 10:46:38 -0400 (EDT)

> Which is a whole load do FUD.

Could you be a little more specific?

Paul