Subject: [DNSOP] CDS and/or CDNSKEY

From: Matthijs Mekking <[email-masked]>
Date: Thu, 26 Sep 2013 09:05:15 +0200

Hi,

I thought it would be good to start a thread about CDS or CDNSKEY, given
the recent discussion on dnssec-deployment.

CDS is a nice proposal for automating the the delegation signer
information at the parent and is able to deal with all possible rollover
scenarios. It's drawback however is that it cannot be used by registries
that require the delegation signer information to submitted as DNSKEY.

There are two straight-forward solutions for this, imo:

1. New RRtype: CDNSKEY
Which is similar to CDS except it publishes the DNSKEY RDATA elements of
the to be DS RRset. A parental agent that calculates the DS itself would
poll for the CDNSKEY RRset.

2. Adjust the CDS RR format
The CDS RDATA is equal to the DNSKEY RDATA plus one RDATA element for
what (preferred) hash is to be used.

The first solution has some minor drawbacks:
* It requires a new RRtype for something that can also be done within an
existing RRtype (CDS after changing the format).
* For the child signer system it would need an additional configuration
knob to decide whether to publish CDS or CDNSKEY.

Adjusting the CDS RR format makes the CDS proposal compliant with both
'requiring DS' and 'requiring DNSKEY' registries.

Best regards,
  Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 Sep 2013 19:27:25 -0700

> the recent discussion on dnssec-deployment.

Thank you!

I'm off at another meeting and that thread got away from me… :-)

> scenarios.

Yup.

> It's drawback however is that it cannot be used by registries

Yup, but the way you have written option 2 (unless I misunderstand) does't allow for "standby keys" .

An option that was discussed (sorry, cannot remember if it was onlist or over a beer) was to have the CDS record be:

RRTYPE <selector> <data>

If the selector is 0, then the data element is a DS record.
If the selector is $something_else then the data is a a DNSKEY. The selector could be the hash type that you would like...

AFAIR, the main objections to this was that it makes parsing *slightly* harder / there is a view that it is less elegant.

So, I *think* basically what you suggested as option 2, but if the "what (preferred) hash is to be used" part is e.g 0, then the data bit is already hashed.

Thoughts?
W

> 
> 
> Best regards,
>  Matthijs
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 27 Sep 2013 07:53:28 +0200

Hi Warren,

On 09/27/2013 04:27 AM, Warren Kumari wrote:
>> I thought it would be good to start a thread about CDS or CDNSKEY,
>> given the recent discussion on dnssec-deployment.
> 
> Thank you!
> 
>> information at the parent and is able to deal with all possible
>> rollover scenarios.
> 
> Yup.
> 
>> It's drawback however is that it cannot be used by registries that
>> require the delegation signer information to submitted as DNSKEY.
>> 
>> 1. New RRtype: CDNSKEY Which is similar to CDS except it publishes
>> the DNSKEY RDATA elements of the to be DS RRset. A parental agent
>> that calculates the DS itself would poll for the CDNSKEY RRset.
>> 
>> 2. Adjust the CDS RR format The CDS RDATA is equal to the DNSKEY
>> RDATA plus one RDATA element for what (preferred) hash is to be
>> used.
>> 
>> The first solution has some minor drawbacks: * It requires a new
>> RRtype for something that can also be done within an existing
>> RRtype (CDS after changing the format). * For the child signer
>> system it would need an additional configuration knob to decide
>> whether to publish CDS or CDNSKEY.
>> 
>> Adjusting the CDS RR format makes the CDS proposal compliant with
>> both 'requiring DS' and 'requiring DNSKEY' registries.
> 
> 

It does allow for standby keys. It allows for anything that the current
specification of CDS allows for (plus more!).

Basically, option 2 is just like the current CDS proposal, but publishes
the information unhashed. The additional RDATA element, call it selector
if you like, informs about how to hash the record.

So if you want a standby key, publish a CDS record for that key, but not
its DNSKEY record.

> An option that was discussed (sorry, cannot remember if it was onlist
> or over a beer) was to have the CDS record be:
> 
> RRTYPE <selector> <data>
> 
> If the selector is 0, then the data element is a DS record. If the
> selector is $something_else then the data is a a DNSKEY. The selector
> could be the hash type that you would like...

This sounds a lot like option 2 here, only this has different RDATA
formats depending on the value of one RDATA element.

> AFAIR, the main objections to this was that it makes parsing
> *slightly* harder / there is a view that it is less elegant.

Yes. I would prefer resource records with a static RDATA format.

> So, I *think* basically what you suggested as option 2, but if the
> "what (preferred) hash is to be used" part is e.g 0, then the data
> bit is already hashed.

What I suggested is always publish a CDS with unhashed information (e.g.
DNSKEY RDATA) + a selector RDATA element on which hash to be used. If
the selector is 0, it is up to the parental agent.

Best regards,
  Matthijs

> 
> Thoughts? W
> 
>> 
>> 
>> Best regards, Matthijs
>> 
>> 
>> _______________________________________________ DNSOP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> -- Do not meddle in the affairs of dragons, for you are crunchy and
> taste good with ketchup.
> 
> 
> 
>