Re: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs

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

Hi Marc,

On 04/18/2011 09:39 AM, Marc Lampo wrote:
> (sorry for the late reply - catching up ...)
> 
> I am not in favour of publishing DS records (in the parent)
> referring towards DNSKEY records that are not present (in the child zone).
>  (is this change seems to propose)

This is a different proposal.

> Motivation :
> As registry we try to protect the chain-of trust towards our customers
> by validating DNSSEC information presented to us.
> Up till now, we have had several cases where such "orphaned" DS records
> actually turned out to be configuration errors.
> As our validation warned about this, we did not contribute to a broken
> chain-of-trust.
> 
> If orphaned DS records were to become common,
> we can no longer easily distinguish between "normal" and "error"
> situation.

You should check if there is at least one DS record that refers to an
existing DNSKEY (per algorithm). Two DS records of which one is pointing
to a DNSKEY record that does exist and one that doesn't is a valid and
thus "normal" situation.

Best regards,

Matthijs

> 
> 
> Kind regards,
> 
> Marc Lampo
> 
>  
> -----Original Message-----
> From: Samuel Weiler [mailto:weiler@watson.org] 
> Sent: 01 April 2011 04:28 PM
> To: dnsext@ietf.org
> Subject: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs
> 
> This is a proposed change in DNSSECbis that changes the mandatory 
> algorithm rules.  I'm posting this as a summary of what I understand 
> some may support; I don't support this change myself. Please post in 
> this thread with your support or lack thereof.
> 
> For additional operational and zone-signing flexibility, particularly
> to allow the publication of a DNSKEY of a new algorithm before a zone
> is fully signed with that algorithm, we propose to change these rules
> to use ONLY the DS RRset for algorithm signalling, not the DNSKEY
> RRset.
> 
> Zones will be required to be signed with each algorithm (though not
> necessarily eack key) present in the zone's DS RRset or configured
> trust anchors.
> 
> My opinion:
> 
> In retrospect, we probably could have used this mechanism when we 
> first wrote these rules -- the choice to use both DS and DNSKEY for 
> signalling may have been an artifact of history.  As it is, this 
> change may cause zones signed under these new rules to fail validation 
> in deployed code, including unbound.  That alone is enough to lead me 
> to oppose this change.
> 
> -- Sam
> 
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNq/f9AAoJEA8yVCPsQCW5sYkH/jo3mKY0x95QNUG/UZW3PkVN
yPmZuFtOD/fFsv1741hfjRWe+BJ5La9XEfC1qc1ukz6JDc4XWlMM7qSzxd5slggZ
hQpK+KC+Nw9sptZQjn/Ym6AHB6251pou629vTjmBTKua/1Bwa6ZlRyH8+fo0BuPh
xlrPVkfJlDXEQE+jScHBlIBGW80jYjrndxIJysPPiLeapONuOuJtu/8GHITMSjES
TYDJ/xu1DkJut9pdO53xu50C2xzJhHRTqnRRO73Szq6VYjwd9Bh7/q6SrhJfeNNY
+aneBoGOuOMIIes0o5o4LMprsBxBtqjy/UnfkWZ9Ac3qQ27VT0S3y+5itvIgPNE=
=PKi5
-----END PGP SIGNATURE-----