Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

[Olafur Gudmundsson <[e-mail]>]

On Jul 1, 2013, at 9:25 AM, Matthijs Mekking <[e-mail]> wrote:

> Hi Olafur,
> 
> On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote:
>> 
>> On Jun 25, 2013, at 6:05 AM, Matthijs Mekking <[e-mail]> wrote:
>> 
>>> 
>>> * Nit: In section 1, it says there may be two interactions with the
>>> parent. This could also be only one, this could be more in some freaky
>>> rollovers, so I would prefer that it reads: "there may be one ore more
>>> interactions with the parent".
>> 
>> Applied 
>> 
>>> 
>>> * Section 3. I appreciate that most ZSK /KSK terminology is carefully
>>> replaced with, but in section 3 is still something that itches: "The SEP
>>> bit is an optional bit to indicate that the key is allowed to sign the
>>> DNSKEY RRset". That is not true. Without the SEP bit, the key may also
>>> sign the DNSKEY RRset.
>>> 
>> 
>> I agree but still want to bring up the SEP bit, 
>> would some thing like this be better: 
>> "The SEP bit is an optional bit that indicates that the child expects to sign the
>> DNSKEY RRset with that key, while the key is in use." 
> 
> This text is better. Still, I want to propose text:
> 
> "The SEP bit, if set, indicates that the DNSKEY is intended for use as a
> secure entry point, thus are used to sign the DNSKEY RRset, and the
> Parental Agent can calculate DS records based on that."
> 

I applied this text with the change "used to sign" --> "expected to sign" 

> This removes the notion of optional (strictly the bit is not optional,
> the setting of it is).
> 
>> 
>>> 
>>> * Section 4.2. It is suggested that RFC 5011-like hold down timers are
>>> being used, e.g. new keying information must be published for a month
>>> before acceptance as a new trust anchor. This makes the duration of key
>>> rollovers unnecessary long. The hold down timers in RFC 5011 are there
>>> to mitigate against a compromise. The compromise allows the attacker to
>>> sign data in the zone.
>> 
>> I hear you and want other people to chime in, both in the context of 
>> compromise and time to perform rollover. If rollover is done by 
>> automated systems that perform checks before progressing who cares how long the 
>> rollover takes? 
> 
> It depends on what you gain with the long wait. I said in my e-mail that
> for me it makes sense to do hold down timers in the RFC5011 case, but we
> don't need to be that conservative with CDS. But I guess it has to do
> with local policy, what checks you require.
> 
> I don't have very strong feelings about this. I just want to see it as
> fast as possible:). I guess if everything is done automagically, this is
> less of a pain.
> 
> A nit drawback I see is that during the transition period you have to
> deal with a larger DNSKEY and/or DS RRset.
> 
> 

I understand when a Human is involved in key rollover you want it to happen as 
fast as possible to minimize the chance of her forgetting a step. 
When this is fully automated in tools why is fast needed ? 

>>> 
>>> Similar we could look at a compromise that allows the attacker to upload
>>> a DS/DNSKEY to the parent. However, there are no mechanisms to mitigate
>>> against this attack. Why should we have mitigation for the CDS proposal,
>>> if there is none for the current mechanism?
>>> 
>>> The difference between CDS and RFC 5011 is the location of the trust
>>> anchor your are updating. With CDS, you are updating the DS in the
>>> parent. With RFC 5011, you are updating lots of trust anchors in the
>>> wild. The latter may indeed require a bit more conservative approach.
>>> 
>>> * Section 4.3. I wonder if the SHOULD in the first sentence should be a
>>> MUST.
>>> 
>> I think a better way is to encourage the child to ONLY publish CDS when there is a need to change the DS record and
>> remove after parents performs change. 
> 
> I prefer the approach where the CDS represents what DS should be in the
> parent. You can make checks: if it is the same, we are in sync. If not,
> the parental agent still has work to do.
> 
> Adding behavior to remove the CDS again after the update has taken place
> at all parent name servers, makes the usage at the child unnecessary
> complex.
> 

I got a comment off-line saying it is better for Parents that Mandating CDS removal as then there is no 
question at parent side as what to do. When CDS is present parent needs to perform checks it is in sync. 
For now I will leave this as an open issue, 

> 
> 
>>> * Section 4.4. I dislike the idea of the side effect of parent
>>> calculates DS, so I would like to see that only the "augment" mode is
>>> supported (where I think it should read: "it will make sure there are
>>> CDS records for the digest algorithm(s) it require(s)" (CDS instead of
>>> DS)).
>>> 
>> 
>> You are not alone, but there are some people in your neighborhood that 
>> feel strongly the other way and argued strongly against version 01 because 
>> this was outlawed. 
> 
> Hm, yes. And I remember that they require the DNSKEY too. Still, I would
> still like to see that the CDS should match the "to be calculated DS".
> 

> 
>>> The publishing "Future DNSKEYs" does not go well with several rollover
>>> scenarios (those based on Double-DS). I am wondering if the policy is
>>> "We calculate the DS" or "We decide the digest algorithm". In case of
>>> the latter, then augment mode can be used to support this. In case of
>>> the first, the future DNSKEY is really required to be published, and
>>> Double-DS based rollovers are not possible in combination with CDS.
>>> 
>> 
>> exactly 
>> 
>>> * Section 6. Security Considerations. The last paragraph. Isn't this
>>> solved by saying that the Parental Agent MUST ensure that old versions
>>> of the CDS RRset do not override newer versions in section 4.3. Usage?
>>> There is already a proposed method on how to achieve this there.
>>> 
>> 
>> Strictly speaking using RFC5011 will address this as all the signatures in 
>> "disjoint" authorative servers wil have expired. 
> 
>>> * When implementing a prototype for this in OpenDNSSEC, I questioned
>>> myself what value I should use for the TTL. We could consider 0, as this
>>> record is not really intended for the resolver. We could also use the
>>> TTL to suggest a polling frequency for the parental agent. Just some
>>> thoughts.
>>> 
>>> 
>> I had not thought about guidance on the CDS TTL, nor on the signature lifetime on the record. 
>> You have any ideas? 
> 
> I just set it to the DNSKEY TTL currently. In OpenDNSSEC you can only
> set different signature lifetime for NSEC(3) and the rest, so nothing
> special there for CDS either.
> 
> I don't think we need special guidance.
> 
> The only idea I had, I already mentioned is that we could use the TTL
> field to signal a polling frequency.
> 
RFC5011 sets polling frequency based on TTL and Signature Lifetime. 

Thanks for your comments. 

	Olafur

> 
> Best regards,
>  Matthijs
> 
> 
> 
>> 
>> 
>>> Best regards,
>>> Matthijs
>>> 
>> Thanks for great review. 
>> 
>> 	Olafur
>> 
>> 
>