On Fri, Apr 11, 2014 at 5:36 AM, Matthijs Mekking <matth...@nlnetlabs.nl> wrote: > Hi, > > > On 04/10/2014 09:54 PM, Patrik Fältström wrote: >>>>> 2.2.1. Solution Space >>>> : : >>>>> Some parents want the child to express their DNSKEYS in the >>>>> form of DS records, while others want to receive the DNSKEY >>>>> records and calculate the DS records themselves. There is no >>>>> consensus on which method is better; both have good reasons to >>>>> exist. The proposal below can operate with both models, but >>>>> the child needs to be aware of the parental policies. >>>> >>>> Mumble...I really dislike the fact we have not agreed on what to >>>> do. It increases complexity _a_lot_. And yes, this is one of the >>>> reasons why we do not see more deployment of DNSSEC. >>>> >>>> Why do we (IETF) fail on this? >>>> >>> >>> Yes; however, we want this to be deployed and usable by as many >>> people as possible, so we are avoiding the religious argument in >>> this document. Registry operators are entitled to their own >>> opinion, as much as we dislike it.... >> >> This is not YOUR fault, and you can not fix this problem in THIS >> draft. I just find it being...not fun. > > I had proposed to have one CDS record that has the RDATA identical as > the DNSKEY record, plus a hash digest type field. For example: > > example.com. 86400 IN CDS *1* 257 3 8 AwEAA... > > This would work for both agents that want DS and agents that want > DNSKEY. Counter arguments from Warren were: > > 1. No, because now the parents who want DS are not getting DS -- they > are getting DNSKEY. > > My understanding was that the reason why parents want DS is so that the > child can determine the hash digest to be used. So the format of the CDS > record does not really matter. > > 2. Some children want to be able to publish a DS record, but not expose > the DNSKEY until they start using it -- the method you have described > doesn't allow for that > > Why would you not want to expose the DNSKEY that you are going to use?
Some folk believe that publishing only the DS, and keeping the standby DNSKEY in your pocket for later use is "safer". By only publishing the DS, the attacker cannot see the DNSKEY and so cannot try factor it. It doesn't matter is this is a valid concern or not -- it's a viewpoint that some hold and so we should accomodate it. > > I had not yet received good responses for my 'counter-counter' > questions. But if Warren's arguments are valid, then having two > different records is imo the cleanest solution. > > >>>>> 4.1. CDS / CDNSKEY processing rules >>>>> >>>>> If there are no CDS / CDNSKEY resource records in the child, >>>>> this signals that no change should be made to the current DS >>>>> set. This means that, once the child and parent are in sync, >>>>> the child DNS operator MAY remove all CDS records from the >>>>> zone. >>>> >>>> I am really nervous we will have a state enforced somewhere, that >>>> must remember what has happened. I much rather want to see the >>>> child always have CDS/CDNSKEY for the proper key set. >>>> >>>> So, there must be a reason why this is not allowed? >>> >>> Much of the point of this is to *avoid* the parent having to keep >>> state. If it queries the zone and sees no CDS records, it simply >>> goes back to sleep. > > If the child will maintain the CDS/CDNSKEY RRset in its zone, the only > extra step the parental agent has to make is to do a compare and if the > compare returns 'in-sync', it simply goes back to sleep. Yup. > >>> Let's say that example.com is signed but has never used CDS / >>> CDNSKEY (like every signed zone currently is). We really don't want >>> the parent going through and removing DS records because there is >>> no CDS published :-) By having a "take no action if there is no >>> CDS/CNSKEY" rule the parent doesn't need to track which children >>> use this. > > But you have to do the polling anyway. And there is no tracking or > maintaining state for the parent if the child maintains the CDS/CDNSKEY > RRset. > > So, it makes it marginally more difficult (one compare per poll) for the > parent, while the rule of removing the CDS/CDNSKEY RRset when in-sync > makes it much more complex for the child, with all the polling and > additional state it needs to maintain. Yup. I just posted mail to the list (Argh! Forgot a subject on the mail!) asking for feedback on which folk would prefer. I personally like the "just leave the record in the zone" view. Hopefully others will too... > > >>>>> When the Parent DS is "in-sync" with the CDS / CDNSKEY, the >>>>> Child DNS Operator MAY delete the CDS / CDNSKEY RRset(s). >>>> >>>> See above. How does the child know? Do you because of this >>>> require the child to poll the parent zone? And if the parent want >>>> to re-fetch the data for some reason, it might be gone from the >>>> child zone. Not good. >>> >>> Yes, the child checks the parent to see if it's in sync. A number >>> of working group participants (I had thought yourself included), >>> had indicated that they would rather have this as more of a >>> transaction system, so that the user publishes a record, the >>> parental agent performs the operation, and then the user is >>> expected to remove the "instruction." The reason for this was so >>> that the user's intent is clear and parental agents can, if they >>> wish, log the "transaction." I will see if I can find references to >>> that (it's not noted in the minutes, but I think Antoin Verschuren >>> said it and a bunch of other folk agreed). >> >> See above. >> >> I am lazy as a programmer. I do not want people to start to REQUIRE >> the CDS/CDNSKEY to be removed. It must be perfectly ok to have the >> CDS/CDNSKEY in the zone all the time. > > I am a programmer. I do not want to track and remove the CDS/CDNSKEY if > they are in-sync. > >> Maybe I am more relaxed if you explicitly say that is a normal case. > > Fully agree. > > >>>>> A child MAY publish both CDS and CDNSKEY. If a child chooses >>>>> to publish both, it SHOULD attempt to maintain consistency (a >>>>> matching CDS for each CDNSKEY) >>>> >>>> No, it MUST represent the same data. Please! >>> >>> DONE. It seems like you feel strongly about this :-) My reason for >>> originally having this as a SHOULD are described above (expecting >>> users the follow a MUST leads to implementers to treat "violations" >>> of the MUST as an error...). But, seems like I'm off in the rough, >>> changed... >> >> Ha ha ha... >> >> See above, I now understand. >> >> I want to know what happens both from the child and parent >> perspective IF the CDS and CDNSKEY differs. >> >> Just say what the result should be. >> >> Parent pick one at random? > > At random? Then you still don't really know that the result would be ;) Hopefully the text is now clearer. The parent should choose either DS *or* DNSKEY (based upon local registry policy - they have already done this). They then poll for the corresponding RR (CDS *or* CDNSKEY) and ignore the other one. > > Best regards, > Matthijs > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
