Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13

[Antoin Verschuren <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16-10-12 16:03, Matthijs Mekking wrote:
> Hi all,
> 
> The document draft-ietf-dnsop-rfc464bis-13 has seen some issues
> while being in AUTH and RCF-EDITOR state. This e-mail will list all
> the suggested changes to address those issues.

While reading the proposed changes and the whole document again, I
noticed another paragraph that is no longer desired.
My question is that now that we do make some changes, it is advised
that this paragraph is also adjusted to fit current day practices.

The paragraph is 4.3.2.
The advice in this paragraph, which hasn't changed since 2009 when it
was first written down, has been overtaken by new insight and practices.
It advises registries to store only DS in stead of DNSKEY material in
their database. This has proven to be impractical when deploying
DNSSEC on a large scale:

1. Current practice proves that the majority of DNSSEC domains in the
world today is provisioned by sending a DNSKEY record to te registry,
and not DS. Running code for the majority of DNSSEC domains uses DNSKEY.

2. The old advice is based on the assumption that less errors are
being made when cutting and pasting a DS in a webinterface or reading
it since it is smaller than a DNSKEY. Current practice today however
is that this is all automated, and while provisioning 1.3 M DNSSEC
domains, we have not seen such errors.

3. With more algorithms used for DNSSEC today, and some no longer
advised, registries want to hash the DNSKEY to DS themselves so they
don't need to go through a "contacting every child" nightmare when an
algorithm is no longer supported. The DS is owned by the parent, not
the child. Our practice shows that hashing is a minor operation by the
parent. It takes no real effort whatsoever in computation or time.

4. The most important motivation for us to use DNSKEY is consistancy
with new processes that did not exist in 2009. DNSSEC secure transfers
(http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt)
is the most important one. In a DNS-operator change, the operator
initiating the change needs to send his new KSK (DNSKEY/DS) to the
registry AND needs to relay his ZSK (DNSKEY). It is confusing that in
bootstrapping a delegation a DS needs to be sent, but when transfering
a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in
both processes so a child operator is never burdened with calculating
a DS or having to think about 2 different fields in EPP that do not
have the same meaning. So our advise is to use DNSKEY syntax for both
KSK and ZSK when transfering to your parent.

So my advise is to either delete paragraph 4.3.2 since it is bad
advice (there is no convincing motivation given in this paragraph
anyway), or use the motivation given above to advise for using DNSKEY
over DS.

If needed, I'm willing to write text.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: [phone]  F: [phone]  M: [phone]
mailto:[e-mail]  xmpp:[e-mail]
http://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJQhoBVAAoJEDqHrM883AgngBMH/1e5LxpQrZNLJ/lV5kp2OJFx
WWsKM2joRSSpW+fc/CMp6gQ5kMs32TqjAk3SLGcUEnKKU1L4zBOPIPzHNfyryqEp
+Mckt+LGtC9/OngjTtfKGvfejLmUormu0zmwSTW5hJqUi16lz4chHosJtvI3JNpZ
s73gDUW11zAxomyJw3bkBOQQgPklpV+7IOAGMeRkxXPUWvhMaPYsGwppZFI4nX49
Bw5zYytnL9YbfdK+LzY7DY5j3ZoEVV6056w7Gn2U4or8IBTQxquR9rpA0XHmrYPv
C07lSeDdwu7jGrv4Qt2ORcZwjvSVYmDD5q3q84w8ZAe7/LU7JAiRaTPIrOBHmoc=
=HVX8
-----END PGP SIGNATURE-----