Subject: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-auto-cpsync-00

From: Matthijs Mekking <[email-masked]>
Date: Tue, 29 Jun 2010 15:19:54 +0200

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.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 29 Jun 2010 16:09:19 +0200

And here's the link:

http://www.ietf.org/id/draft-mekking-dnsop-auto-cpsync-00.txt

On 06/29/2010 03:19 PM, Matthijs Mekking wrote:
> -------- Original Message --------
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 29 Jun 2010 08:32:07 -0600

HI Matthijs,

I like this draft but I'm a little bit concerned about the scalability.
How will a busy parent provision a unique secret key for each of the
child? And how will this key be transported between the parent and the
child in a secure way?

Thanks, Stephan
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Matthijs Mekking
> Sent: Tuesday, June 29, 2010 9:09 AM
> To: [email-masked]
> Subject: Re: [DNSOP] Fwd: New Version Notificationfor
draft-mekking-dnsop-
> auto-cpsync-00
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> And here's the link:
> 
> > Title:		 Automated (DNSSEC) Child Parent Synchronization
using
> DNS UPDATE
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJMKf6PAAoJEA8yVCPsQCW5T+8H/0DtagyXJJ7P1tzPyk/QNBuG
> LvQu7VLy7lgwMquu9AnHkugXRVyf4KJ7cWduNTyVSjqmoZ0tZc9tWfJ26QQjDk65
> amjWuXA9YKd21eili10jEOyjn13RIbOAO9c64VJHtmGubO+Ct5l7TUL8JKt+R6FB
> pGQT5LjXRGhA7KDKVNDCgtXHBbmMwr6Iwg4A2PrHQ7DxBRfALRlmzrx7PNjABh3q
> JTNiC0RYbSljq6Hi9fGOYse+QN4WoyAQS6PHLwMVKhZA2vFWBnz3mrgC1hQw6ysg
> x41nqvKqgc8PohiA8ZsERPdfpEBPw11n0zBvI09nttPVEVL+EwttbCLoIzDqXys=
> =ovIB
> -----END PGP SIGNATURE-----

---

From: Wolfgang Nagele <[email-masked]>
Date: Tue, 29 Jun 2010 16:43:34 +0200

Hi Stephan,

> child?
Do you mean the scalability for capacity on the update server side? Although
BIND might not be able to scale this out of the box, the example has only been
given in the draft to have a hands-on way for ppl to try this draft.

In reality it should not be a major issue to receive those DNS updates and
process them (with or without signatures) - similar efforts are currently made
for each request to change NS-sets on the parent (admittedly those might happen
less frequent).

> And how will this key be transported between the parent and the
> child in a secure way?
The same way a parent is currently providing a domain owner with credentials for
their management interfaces. If a domain owner has specific requirements in
terms of security on that channel it is something where registrars can offer
whatever their customers demand.

Regards,
Wolfgang

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 29 Jun 2010 09:15:07 -0600

Hi Wolfgang,

My concern was not about the updates but rather about the gigantic
number of keys a busy parent would have to create, revoke, store, renew,
etc. 

It doesn't make sense to me to utilize symmetric encryption (such as
TSIG) to solve this problem. A scheme that utilized an asymmetric key
would be a much better fit. DNSSEC itself would be a strong candidate
here.

Thanks, S

Of
> Wolfgang Nagele
> Sent: Tuesday, June 29, 2010 9:44 AM
> To: Stephan Lagerholm
> Cc: [email-masked]; Matthijs Mekking
> Subject: Re: [DNSOP] Fwd: NewVersion Notificationfor
draft-mekking-dnsop-
> BIND might not be able to scale this out of the box, the example has
only
> been
> process them (with or without signatures) - similar efforts are
currently
> made
> for each request to change NS-sets on the parent (admittedly those
might
> happen
> their management interfaces. If a domain owner has specific
requirements
> in

---

From: Wolfgang Nagele <[email-masked]>
Date: Tue, 29 Jun 2010 18:30:27 +0200

Hi,

> would be a much better fit. DNSSEC itself would be a strong candidate
The draft does not restrict which signature method is to be used. Anything that
DNS update messages support can be employed here. SIG(0) for example.

Also the draft has details about the up- and downside of using an additional
channel via DNS update messages in section 5 (Security Considerations).

Regards,
Wolfgang

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jun 2010 09:27:52 +1000

In message <[email-masked]>, "Ste
> child? And how will this key be transported between the parent and the

How are NS records passed to the parent in a secure manner today?
If a parent can accept the volume of NS records required to delegate
it can generate keys just as fast and send them back over the same
channel.  There is no scaling issue here.

-- 
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: Wed, 30 Jun 2010 11:36:59 +0100

I'd like to encourage some discussion of the relative merits of the UPDATE approach

compared to the publication approach outlined in the recent draft at

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt

I haven't yet done a well-considered analysis, and maybe this would be better
undertaken by others, but here are some of my immediate thoughts:

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.

The publication approach leverages the in-built redundancy of DNS slave servers
for transmitting information, and seems closer to the normal DNS method of operation.

I also like the ability to simply check whether the parent and child DS RRset
are properly synchronised.

I'm a bit doubtful about the complications of setting up additional secret keys for UPDATE.

Regards,
George

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 30 Jun 2010 07:25:48 -0600

Hi Goerge,

What I like about your approach is the fact that is takes advantage of
DNSSEC. My opinion is that if DNSSEC is so great it would be cool if we
can define an update mechanism that utilizes it. This could be the first
real world application for DNSSEC.

I would encourage some type of notification mechanism so that the parent
doesn't have to poll blindly. Also, why not use a DNSKEY with another
flag to announce the availability of a new key instead of a new RR?
Similar to what RFC5011 is doing for a revoked key.

Thanks, S
Of
> George Barwood
> Sent: Wednesday, June 30, 2010 5:37 AM
> To: Matthijs Mekking; [email-masked]
> Subject: Re: [DNSOP] Fwd: New Version
Notificationfordraft-mekking-dnsop-
> auto-cpsync-00
> 
> I'd like to encourage some discussion of the relative merits of the
UPDATE
> approach
> The publication approach leverages the in-built redundancy of DNS
slave
> servers
> for transmitting information, and seems closer to the normal DNS
method of
> operation.
> 
> I also like the ability to simply check whether the parent and child
DS
> RRset
> I'm a bit doubtful about the complications of setting up additional
secret
> keys for UPDATE.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 30 Jun 2010 16:43:32 +0100

----- Original Message ----- 
From: "Stephan Lagerholm" <[email-masked]>
To: "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 30, 2010 2:25 PM
Subject: RE: [DNSOP] Fwd: New Version Notificationfordraft-mekking-dnsop-auto-cpsync-00

> doesn't have to poll blindly. 

Yes, this could be useful. I'm not sure it is essential, or what mechanism would be best.
I haven't looked to see whether NOTIFY could be used, or possibly a new opcode.

> Also, why not use a DNSKEY with another

It is probably possible to use the DNSKEY RR with flags. However I think using
the CDS record has several advantages ( that I should possibly incorporate into the draft ).

(1) It allows the DS to be published without revealing the public key. This means an adversary
cannot start cryptanalysis at this point.

(2) The size of the DNSKEY RRset does not vary while the rollover is being performed.
Given the transport constraints, this seems a significant advantage.

(3) Finally, it may be useful in future to be able to publish arbitrary DS records,
which may not necessarily correspond to any DNSKEY. An example of this can be
seen in this draft

http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-18#section-3.12

where a special DS record is used to encode link-level transport information,
allowing DNS traffic to be encrypted.

Thanks for your comments,
George

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Jun 2010 17:58:51 +0100

> real world application for DNSSEC.

That prize has already been taken. See the CERT RR described in RFC 4398,
the IPSECKEY RR described in RFC 4025, the SSHFP RR described in RFC 4255
(supported by OpenSSH), never mind secure UPDATE and NOTIFY.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING: NORTHWESTERLY 4 VEERING SOUTHEASTERLY 4 OR 5, INCREASING 6 IN WEST
LATER. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 30 Jun 2010 19:31:31 +0200

Stephan,

There were acknowledged some drawbacks of using DNSSEC as the security
channel in this specific case. One is that you still do not cover
unscheduled key rollovers, as that event may occur as a result of a
compromised key. It is possible to cover if you use a different security
channel, as is described in the section 'Security Considerations'.
Another drawback is that a proxy parent (for example the registrar)
might not have the appropriate material available to use DNSSEC
verification.

Also, the intention of the memo is to provide a more general solution to
synchronize records between child and parent, which covers all required
records (not only DS) and can be used in all situations.

Best regards,

Matthijs