Subject: Re: [DNSOP] Fwd: New Version Notification fordraft-mekking-dnsop-auto-cpsync-00

From: Wolfgang Nagele <[email-masked]>
Date: Thu, 01 Jul 2010 20:43:48 +0200

Hi,

> I think the publication approach is somewhat simpler, at least for the child zone.
> It's very simple for signing software (including off-line signers) to generate the "CDS" RRset.
> Since there are many more child zones than parent zones, this seems significant.
Not sure i can agree with that. The UPDATE the child has to send can be
performed completely with existing tools ('nsupdate' from BIND as one example).
I don't think it's more or less complex than including a record inside of the
zone. This however is a decision we as those who are writing the drafts should
not decide but leave it up to the end-user.

Regards,
Wolfgang

---

From: Shane Kerr <[email-masked]>
Date: Thu, 01 Jul 2010 22:01:11 +0200

Wolfgang,

> not decide but leave it up to the end-user.

I do think that publishing some new RR in a zone is simpler. In fact, as
a child zone maintainer, I can do it today without any changes to
existing software. So, I like the simplicity of George's draft.

I also like that George's draft only concerns itself with DS data, and
that the child doesn't have to know anything about its parent.

I do think that George's approach only makes sense if some more work is
done fleshing out the actual algorithm the parent uses. For example,
what happens when some of the child name servers disagree? The algorithm
need not be too complex, but the devil is in the details.

And ultimately I do think some sort of NOTIFY-like mechanism would be
cool with George's approach, although clearly not necessary. Key rolling
is less time sensitive than updating an NS RRSET, unless you need an
emergency roll, in which case it's time to contact the administrator of
your parent zone!

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Jul 2010 13:42:23 +1000

> need not be too complex, but the devil is in the details.

So what's so hard about:

nsupdate
key isc.org <secret>
update delete isc.org DS
update add isc.org 86400 DS ...
update add isc.org 86400 DS ...
send

to update the DS's?

nsupdate
key isc.org <secret>
zone org
update delete isc.org NS
update add isc.org 86400 NS ...
update add isc.org 86400 NS ... 
send

to update the NS's?

It scales.  It is secure.  It works with any type.  It does not
depend apon DNSSEC so it works for everyone now.

If one wants to send updates to a seperate server one can and that
can feed into the EPP system so one doesn't have to change the
existing nameservers configurations.  Sending to other servers can
be formalised by using SRV so it can be auto discovered.  The update
server would have access to the EPP database for TSIGs.

nsupdate
server <updateserver> [<port>]
key isc.org <secret>
zone org
update delete isc.org NS
update add isc.org 86400 NS ...
update add isc.org 86400 NS ... 
send

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "George Barwood" <[email-masked]>
Date: Fri, 2 Jul 2010 06:36:08 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "Shane Kerr" <[email-masked]>
Cc: "Wolfgang Nagele" <[email-masked]>; <[email-masked]>
Sent: Friday, July 02, 2010 4:42 AM
Subject: Re: [DNSOP] Fwd: New Version Notificationfordraft-mekking-dnsop-auto-cpsync-00

[snip]

> update add isc.org 86400 DS ...

This implies extra infrastructure to generate and securely transmit <secret> between
the parent and child, and administrative activity to set this up somehow.

The publication method does not imply any administrative action other than updating
the DNS software and activating the DNSSEC feature.

- George

---

From: Wolfgang Nagele <[email-masked]>
Date: Fri, 02 Jul 2010 09:13:03 +0200

Hi,

> the DNS software and activating the DNSSEC feature.
Maybe i am missing something here, but with the publication method you also have
the bootstrap that has to happen out-of-band. Meaning i as a child will always
have to provide my parent in a secure way (which is not established by then)
with my initial (C)DS record. Why not use that step to perform above mentioned
exchange?

Regards,
Wolfgang

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Jul 2010 17:42:15 +1000

> the parent and child, and administrative activity to set this up somehow.

I regularly use TSIG today between my master server and the slave
servers for my zones operated by other parties.  TSIG really isn't
a hard thing to setup or use.  In many cases it's no harder than
clicking on a button that generates a TSIG key that can be
cut-and-pasted into the nameservers configuration on a https protected
page.  This is what I would expect would happen with TLD's via the
registrars.

In other cases I've generated the key and sent it to the slave.

> the DNS software and activating the DNSSEC feature.

Publication also requires a secure exchange of crypto material.

Mark

---

From: "George Barwood" <[email-masked]>
Date: Fri, 2 Jul 2010 08:41:33 +0100

----- Original Message ----- 
From: "Wolfgang Nagele" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Mark Andrews" <[email-masked]>; <[email-masked]>
Sent: Friday, July 02, 2010 8:13 AM
Subject: Re: [DNSOP] Fwd: New Version Notificationfordraft-mekking-dnsop-auto-cpsync-00

> with my initial (C)DS record. Why not use that step to perform above mentioned

There doesn't have to be any secure initial exchange.

Looking at the process from the domain owner point of view, DNSSEC is enabled.
The signing software produces the CDS record.
He checks the DS record in the parent, and is now assured that all is well,
the zone is secure, and will be secure from this point.

The situation is not so good from the consumer point of view though.
The consumer has to assume that the domain owner has followed the above steps.
So there is a trade off between getting as many domains signed as possible with
minimal administrative overhead, and an assurance that signed domains really have been
signed by the domain owner ( rather than say an attacker who has inserted the DS in the
parent zone by attacking the insecure initial transfer ).

That's why I say in the draft 

"If the authentication succeeds, or yields Insecure, extra security checks MAY be performed."

I think the standard should allow parent zones to make the above trade-off as they see fit.

My inclination is to push the responsibility onto the domain owner. It's an incentive to
actually deploy DNSSEC. The consumer is always in a weak position, in that he can
never be sure whether the domain owner is operating securely, so this assumption is
unavoidable.

I would hope that at some point in the future, it will be implicit that any large/trusted 
company will have created and verified it's DS RRset.

Regards,
George

---

From: "George Barwood" <[email-masked]>
Date: Fri, 2 Jul 2010 15:16:11 +0100

----- Original Message ----- 
From: "Shane Kerr" <[email-masked]>
To: "Wolfgang Nagele" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 01, 2010 9:01 PM
Subject: Re: [DNSOP] Fwd: New Version Notification fordraft-mekking-dnsop-auto-cpsync-00

> what happens when some of the child name servers disagree? 

Well I don't expect the parent to consult multiple servers, unless some servers are non-responsive,
but yes,  there could be problems with incoherence.

The parent server might see the new CDS RRset on one nameserver,
but later fetch the old one from a slave that has not yet been updated,
which could result in the new DS appearing, and then disappearing (bad).

I guess the parent should check the signature inception of the RRSIG for the CDS,
and ignore the RRset if the signature inception has decreased ( serial number arithmetic ).

I will incorporate that in the next version of the draft unless someone comes up with a better idea.

- George

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Jul 2010 11:11:13 -0400

On Fri, Jul 02, 2010 at 05:42:15PM +1000, Mark Andrews wrote:
> a hard thing to setup or use.

It may surprise you to learn that there are users who do not find the
user interface for these tools, or the idea of cutting and pasting
into BIND config files, even slightly intuitive.  I've personally
encountered situations where it took weeks to set up TSIG between two
servers.  Anything that makes this sort of thing easier seems to me to
be a good idea.  (This is not an evaluation of the current proposal,
just an observation.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Wolfgang Nagele <[email-masked]>
Date: Fri, 02 Jul 2010 19:47:17 +0200

Hi,

> be a good idea.  (This is not an evaluation of the current proposal,
I can second that. It is not a good idea to look at the audience here as the
datapoint for what is easy and what not.

Cheers,
Wolfgang

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 3 Jul 2010 20:02:14 +0200

> with my initial (C)DS record. Why not use that step to perform above mentioned

The possibility to use a non-DNSSEC scheme for authentication is one of the reasons I support this draft. Any parent/child API does need a shared secret (or keypair), whether it is used for a RESTful HTTP API or dynamic DNS UPDATE doesn't change this. Trying to reuse DNSSEC itself for this authentication, and still support both the initial key transfer and key rollover in case of key compromise, does IMHO not fly.

	jakob

--
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 3 Jul 2010 20:03:54 +0200

> be a good idea.  (This is not an evaluation of the current proposal,

One might recall how wonderful the original secondary.com (a secondary DNS service once upon a time run by Nominum) gave the administrator real BIND configuration sniplets as part of setting up TSIG. Anyone being abel to edit named.conf could configure TSIG using this type of setup.

	jakob

---

From: [email-masked]
Date: Sat, 3 Jul 2010 22:17:23 +0000

thanks for this.  :)

--bill

On Tue, Jun 29, 2010 at 03:19:54PM +0200, Matthijs Mekking wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> FYI,
> 
> I have submitted this draft on the topic of automatic update of DS (and
> other records).
> 
> Best regards,
> 
> Matthijs Mekking
> NLnet Labs
> 
> - -------- Original Message --------
> Subject: New Version Notification for draft-mekking-dnsop-auto-cpsync-00
> Date: Tue, 29 Jun 2010 06:12:35 -0700 (PDT)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> 
> 
> A new version of I-D, draft-mekking-dnsop-auto-cpsync-00.txt has been
> successfully submitted by Matthijs Mekking and posted to the IETF
> repository.
> 
> Filename:	 draft-mekking-dnsop-auto-cpsync
> Revision:	 00
> Title:		 Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
> Creation_date:	 2010-06-29
> WG ID:		 Independent Submission
> Number_of_pages: 6
> 
> Abstract:
> This document proposes a way to synchronise existing trust anchors
> automatically between a child zone and its parent.  The algorithm can
> be used for other Resource Records that are required to delegate from
> a parent to a child such as NS and glue records.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJMKfL6AAoJEA8yVCPsQCW5MA8IALsVN2C0raqTybHDtdWqkS19
> uOeKyTP7HvJXXYNbRwbITjDzTyx1aFWuNV+JGou16vlXyJY4gK0Ob3Y6P9aum/L3
> LvCD/6ekPDL4VxwoJFwq1GsudBnNGN9UeO8IK1R2gNmraEiGAcJ7imovc5+YW5wy
> Ihk0t5hEAfhgk/2Nr6pguZBxfz2bbpAyBBaZd0uyLBszwnKNWKLVoWxDpBhfOwgA
> MOWB9owHodjRa6yrJlNJ0IBvdwhC+SyIWyptAwRR810wE3slzYS8xOk1Uvd7a8lF
> cVeint1z/KxFCPvY69UsnFoOpmgrNwG6cmw8Zg5SEfDpHlswfsbn2BNSo6B07FE=
> =0u03
> -----END PGP SIGNATURE-----