Hi Olafur, On 06/28/2013 08:18 PM, Olafur Gudmundsson wrote: > > On Jun 25, 2013, at 6:05 AM, Matthijs Mekking <[email protected]> wrote: > >> Hi, >> >> On 06/21/2013 11:58 PM, Wes Hardaker wrote: >>> Paul Wouters <[email protected]> writes: >>> >>>> I am in favour of adopting this draft as a WG item. >>> >>> Ditto. >> >> Another ditto. I am pleased to see that there is still activity on the >> topic of automating the synchronization between DNSKEY at the child and >> the DS at the parent. >> >> > Thanks > >>>> I don't think the CDS record should be able to cause a child domain to >>>> go from secure to insecure, or from insecure to secure. That >>>> (infrequent) change should have an additional authentication, eg via EPP >>>> or otherwise) >>> >>> Ditto. I think the goal of any of the automatic update techniques >>> should be to make the routine easy but it shouldn't be a goal to handle >>> the infrequent, and challenging cases. (infrequent and easy is fine). >>> >>> Unless we can show a clear, secured, path for some transition I don't >>> think it's worth solving. >> >> Another ditto. Agreeing with it's not worth solving to deal with the >> irregular cases. Going unsigned is an irregular case. >> >> >> Also backing a previous made comment by other people: >> >> * I prefer to have the CDS wire format to be similar to the DS wire >> format. With the current draft, it is already possible to automate all >> possible key rollovers, no need for managerial hooks to say this record >> is proposed, must be added, deleted, is valid for only this period etc. >> >> > >> Comments on the draft (apologies for its length): > > Thanks for the comments. > >> >> * 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." This removes the notion of optional (strictly the bit is not optional, the setting of it is). >> * Section 3.1.1. As said above, I don't like the idea of using the CDS >> record to go unsigned. >> > > Ack, > this is going to be a design point allow or not allow this function. > We can remove this part and later propose it as part of an extension, just > like > any protocol to automate the tickling of the parent. > >> * Nit: Section 4.1. I think the last paragraph fits better in section >> 4.2. CDS Consumption. > > Reworked both sections to address this >> >> * Section 4.2. About the polling strategy. I am wondering how well this >> scales with respect to the number of delegations. > > The next version will indicate that polling has scaling issues, but punt the > problem of > defining a mechanishm to another document. > The thinking is the "parental notification" is the HARDEST part of the > proposal, > and we might need multiple solutions depending number of delegations and > other factors. > Having said that in many cases in particular the enterprise and university > cases polling is perfectly fine > and will scale, thus our thinking is we will document that and start a > parallel document on "MAGIC" system > that does the notification, along the lines you documented few years back. > >> >> * 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. >> >> 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. >> * 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. Best regards, Matthijs > > >> Best regards, >> Matthijs >> > Thanks for great review. > > Olafur > > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
