Re: [DNSOP] CDS and/or CDNSKEY

[Warren Kumari <[e-mail]>]

On Sep 27, 2013, at 1:53 AM, Matthijs Mekking <[e-mail]> wrote:

> Hi Warren,
> 
> On 09/27/2013 04:27 AM, Warren Kumari wrote:
>> 
>> On Sep 26, 2013, at 12:05 AM, Matthijs Mekking
>> <[e-mail]> wrote:
>> 
>>> Hi,
>>> 
>>> I thought it would be good to start a thread about CDS or CDNSKEY,
>>> given the recent discussion on dnssec-deployment.
>> 
>> Thank you!
>> 
>> I'm off at another meeting and that thread got away from me… :-)
>> 
>>> 
>>> 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.
>> 
>> Yup.
>> 
>>> 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.
>> 
>> 
>> Yup, but the way you have written option 2 (unless I misunderstand)
>> does't allow for "standby keys" .
> 
> 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.
> 

Hi all.

Anyway, we have finally rev'ed the CDS draft, and have (I think) arrived at a compromise that will be acceptable to both views (DS vs DNSKEY).

The 50'000ft[0] view is that the record is now a selector and a data part.
If the selector is 0, the data is a DS record.
It if is not 0, the data is a DNSKEY, and the parent should calculate the DS from that.
(This is largely based upon ideas like that described above. )

This allows children to present DS to those parents who want DS, and DNSKEY to those who would prefer to calculate DS on their children's behalf.


There has been another thread on the whole CDS and CSYNC thing on the DNSSEC-Deployment list (which I'm assuming most folk here have been following as well).

We (the authors or CDS and CSYNC) have had a number of discussions comparing the various pros and cons of draft-kumari-ogud-dnsop-cds (CDS) and draft-hardaker-dnsop-csync (CSYNC). As we we discussed at the DNSOP session in Berlin, we believe that there are *complementary* but *different* solutions.

CSYNC is designed for transferring various delegation information, such as NS, A/AAA glue, etc. It does this by publishing a Type Bit Map of the records that the parent may copy. This means that it copies exactly what is in the child for those types. This makes it unsuitable for DS records, where a child may want to publish DS records for stand-by keys, where they may want to pre-publish a DS records prior to performing key roll, etc. 

CDS (now CTA) is designed specifically for transferring DNSSEC key information from the child to the parent. The child publishes a CTA record containing what they want to parent to publish, and the parent copies this (potentially after computing DS from DNSKEY. This allows for publishing DS records that are not actively in use. CTA *only* handles DS / DNSKEY records, and so does't support the more general solution that CSYNC does -- it is however designed for simplicity.

We have had numerous discussions regarding having a bit in CSYNC that indicates that the parent should look for an updated CTA record. We have come to the conclusion that this is not really worth the bother -- it potentially saves a single poll of the child (if the parent supports both CSYNC and CTA it would have to check for bot) at the expense of additional complexity, corner cases, etc.

So, in summary, we believe that CSYNC and CTA are related, complementary solutions, but solving different use cases. We do not think that coupling them together (nor trying to explain them both in a singe draft) will be helpful.

W

-------------------------
A new version of I-D, draft-kumari-ogud-dnsop-cds-04.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Filename:	 draft-kumari-ogud-dnsop-cds
Revision:	 04
Title:		 Automating DNSSEC delegation trust maintenance
Creation date:	 2013-10-02
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-04.txt
Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-04

Abstract:
  This document describes a method to allow DNS operators to more
  easily update DNSSEC Key Signing Keys using DNS as communication
  channel.  This document does not address the initial configuration of
  trust anchors for a domain.  The technique described is aimed at
  delegations in which it is currently hard to move information from
  the child to parent.

---------------------

W

[0]: or 15240m for those folk who use less entertaining units of measurement

> 
>> 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 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>> 
>> -- Do not meddle in the affairs of dragons, for you are crunchy and
>> taste good with ketchup.
>> 
>> 
>> 
>> 
> 

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)