Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Patrik Fältström <[e-mail]>]

On 11 apr 2014, at 23:48, Warren Kumari <[e-mail]> wrote:

>> This is not YOUR fault, and you can not fix this problem in THIS draft. I just find it being...not fun.
> 
> Yup, me too.
> If they made me President of the Universe:
> 1: SPAM would be a capitol offense.
> 2: All movies **MUST** (RFC2119-style) contain a blooper reel (if
> nothing funny happened while filming, well then film some more...)
> 3: Everyone would take DNSKEYs (I used to think DS but Antoin
> convinced me otherwise....).
> 4: By the time they reach 21, everyone would have to have visited at
> least 3 other countries, with noticeably different language and
> culture (government assistance would be provided to those who really
> cannot afford this on their own).
> 5: Kylie Minogue's "Locomotion" would be banned. I dislike censorship
> as much as the next person, but you have to draw the line somewhere.

Where do I cast my vote?

>> Yup, I did understand this, but just felt it was not really crystal clear enough. I know DNSSEC (I think....:-) ) and still had to look at some of the text a few times to ensure that there where no loopholes.
> 
> I *think* the -04 version addresses this now -- good 'nuff?
> Actually, in my edit buffer (which will become -05 -- "Launch and
> iterate") I have:
> "This proposal does not include all operations needed for the
> maintenance of DNSSEC key material, specifically the initial
> introduction or complete removal of all keys. Because of this,
> alternate communications mechanisms must always exist, potentially
> introducing more complexity."

Excellent!

> In my -05 edit buffer:
> The child SHOULD publish both CDS and CDNSKEY. If the child knows
> which the parent consumes, it MAY choose to only publish that record
> type (for example, some children wish the parent to publish a DS, but
> they wish to keep the DNSKEY "hidden" until needed). If the child
> publishes both, the two RRsets MUST match in content. The parent
> should use whichever one they choose, but SHOULD NOT query for both
> and perform consistency checks between the CDS and CDNSKEY records.
> 
> Note: It is not an error for a child to have published CDS records and
> not have CDNSKEYs that hash to those records, nor for there to be
> CDNSKEY records without matching CDS records. This is because a child
> might have been publishing CDS records and then the parent's policy
> changes to require CDNSKEY records. The child might forget to remove
> the CDS, etc. This avoids all sorts of error conditions / complexity,
> etc"
> 
> Is this better / clearer? I'm uncomfortable with the "If the child
> publishes both, the two RRsets MUST match in content.". It sort of
> sounds like the rdata must be identical. Can anyone suggest better
> text? "the two RRsets MUST have the same semantic meaning?" something?

Excellent.

The rest of the comments are approximately this. You only have to say this once.

>> 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.
>> 
>> Maybe I am more relaxed if you explicitly say that is a normal case.
> 
> Just sent mail to the list explicitly asking which folk would prefer.
> My preference is that children just leave the records around (and
> update the doc to say so). We had originally put this in because
> someone asked us too (and we cannot remember who that was!).
> Hopefully folk will want the behavior you (and Matthijs) are asking for.

We'll see.

>> How often do you click "yes" and "no" when your ssh client show you an initial fingerprint? ;-)
> 
> Well, I never click Yes *and* No :-)

Mumble, I blame a few reports from the Swedish Government on Fibre deployment that was pure crap, lack of coffee and other things.

> Do you like:
> "The delegation user interface has a button {Fetch DS} when pushed
> preforms the CDS / CDNSKEY processing. If the Parent zone does not
> contain DS for this delegation then the "push" SHOULD be ignored. If
> the Parental Agent displays the contents of the CDS / CDSNKEY to the
> user and gets confirmation that this represents their key, the
> Parental Agent MAY use this for initial enrolment (when the Parent
> zone does not contain the DS for this delgation). "

Good!

>>>>> 6.2.  Using the new CDS / CDNSKEY records
>>>>> 
>>>>>  Regardless of how the Parental Agent detected changes to a CDS /
>>>>>  CDNSKEY RR, the Parental Agent MUST use a DNSSEC validator to obtain
>>>>>  a validated CDS / CDNSKEY RRset from the Child zone.  It would be a
>>>>>  good idea if the Parental Agent checked all NS RRs listed at the
>>>>>  delegation.
>>>> 
>>>> What does "would be a good idea" mean in RFC 1918 speak? :-)
>>>> 
>>>> More seriously, no, I do not think that requirement should be there at all.
>>> 
>>> Which one? I'm assuming you are fine with / like the "Parental Agent
>>> MUST use a DNSSEC validator"?
>> 
>> I just wanted to know in official MAY/MUST/SHOULD language what "be a good idea" means first of all.
>> 
>>>> How to handle lame delegation, inability to use cached information, what TTL can be acceptable etc is hidden in this "good idea". Just remove it.
>>>> 
>>>> Either DNS is used to fetch the RR or not.
>>>> 
>>>>>  The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
>>>>>  RRset do not overwrite newer versions.
>>>> 
>>>> I do not think this is a good idea. See above.
>>>> 
>>>> Please remove.
>>>> 
>>>> This is because there is a requirement on state in the parent. I dislike that. Much better if the CDS/CDNSKEY is always reflecting the current state in the child zone. And just say so.
>>> 
>>> This was specifically added because folk asked for it. You have a
>>> "primary" DNS server and a bunch of "secondaries" (by "primary" and
>>> "secondary" I mean you have one server where you make the changes, and
>>> the others all slave from it).
>>> You are in the process of rolling from key BAR to key FOO.
>>> 
>>> You have:
>>> . CDS KEY_FOO on the primary.
>>> and
>>> . CDS KEY_BAR on the secondaries because they have not yet AXFRed the zone.
>>> 
>>> The parent chooses an NS at random - it picks the "primary" and
>>> updates what it publishes for the child.
>>> It then tries again, and happens to hit a "secondary".. and updates
>>> what it publishes for the child.
>>> Lather, rinse, repeat.
>> 
>> No, I absolutely do not like this.
>> 
>> You also have caching, you have lame delegation and a million other things.
>> 
>> This is why we do key rollover with multiple keys.
>> 
>> So you never jump from CDS KEY_FOO to CDS KEY_BAR in one hop. You always have them overlap, OR, you get the problem you talk about. And it is not the parents responsibility to ensure you do not as a child shoot yourself in your foot.
>> 
>> We already have too many parents that have I do not know how many stupid rules for what various values must be in the child hosting situation, and in many cases that make it plain impossible to do what you want as a child. Really silly rules.
>> 
>> Parent should not control the child.
>> 
>> If the child do NOT want the problem you talk about, have overlapping CDS/CDNSKEY. If you want to jump quickly, do what you suggest with non overlapping CDS/CDNSKEY but risk that the wrong DS might be published in parent zone. Up to you as a child.
>> 
>> Compared to many other things that I suggest, I can give up my arguments, but not this. This I must really be convinced why I am wrong.
> 
> Ok. Fair. Removed.

Thank you VERY much!

Hint: Try to register a domain name in the .IS ccTLD. That is the latest hangup I have regarding broken policy by a registry. There are probably others as well, but this is my latest "interesting" case.

   Patrik