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

[Matthijs Mekking]

Hi,

On 04/24/2014 05:41 PM, 神明達哉 wrote:
 At Thu, 24 Apr 2014 07:55:52 +0200,
 Matthijs Mekking matth...@nlnetlabs.nl wrote:
 
 The child can also signal its desire to remove DS records by removing
 the corresponding records from the CDS/CDNSKEY RRset again.
 
 ...unless that would make the resulting CDS/CDNSKEY RRset empty.
 Otherwise it can contradict this one:

Of course. I tried to rephrase it in four short lines. That does not
mean that one line that stands alone is the absolute truth: you have to
consider the complete context.


 If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
 this means there is no action to perform for the parent. Hence, this
 document does not support removing all DS records from the parent.
 
 I guess this discussions is essentially the same as what I asked a few
 months ago:
 http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html
 
 and while I thought revised versions of the draft were clear about
 this point, but the fact that we still have this discussion seems to
 suggest it's probably not sufficiently clear.  Perhaps the problem is
 that many of us already knows how it works and it's difficult for us
 to see how it could be interpreted by first-time readers.  So, while
 it may look redundant, it may help if we show a specific example of
 how the child adds/removes CDS/CDNSKEY and how it works at the parent:

I am indeed pretty clear about how this should work and I think the
draft reflects that. But indeed: there is nothing wrong with adding an
appendix with some examples. Some remarks below:

 0. the child becomes signed from unsigned, tells the parent its
DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
of CDS/CDNSKEY:
child.example. DS (for KSK1)
 1. the child adds the corresponding CDS in the child zone:
child.example. DNSKEY (for KSK1)
child.example. CDS (for KSK1)

The child does not necessarily need to add the CDS now: The parent
already has the correct DS RRset (step 0) and no rollover has happened
since then.


 2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
child zone:
child.example. DNSKEY (for KSK1)
child.example. DNSKEY (for KSK2)
child.example. CDS (for KSK1)
child.example. CDS (for KSK2)

Depending on the type of rollover, the child might not want to add the
CDS directly (Double-Signature KSK Rollover) or might want to add the
CDS before adding the DNSKEY (Double-DS KSK Rollover).


 3. the parent notices or is notified of a change in the child, and
finds there's a new CDS (for KSK2) that doesn't match its set of
CDS, and adds a new DS corresponding to that one:
child.example. DS (for KSK1)
child.example. DS (for KSK2)
 4. the child confirms the DS and CDS are now synchronized, and removes
the old DNSKEY (KSK1) and corresponding CDS:
child.example. DNSKEY (for KSK2)
child.example. CDS (for KSK2)

You want to remove DNSKEY and CDS for KSK1 here.

Again: The old CDS may be removed earlier, at the time of adding the CDS
for KSK2 (Double-Signature) or later (Double-DS).


 5. the parent notices or is notified of a change in the child, and
finds a CDS (for KSK1) that currently matches one of its DS's is
now removed.  the parent removes the corresponding DS:
child.example. DS (for KSK2)
 6. the child confirms the DS and CDS are now synchronized.  at this
point, it MAY remove the remaining CDS for the reason explained in
Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
child.example. DNSKEY (for KSK2)
(no CDS records)
 7. the parent notices the change in the child, but does nothing since
there's no CDS record in the child:
child.example. DS (for KSK2) ; still exist
 8. eventually the child might go unsigned again.  all of its DNSKEYs
will be removed, but the child needs to tell the parent about the
change and have them remove the DS records in some other way than
CDS/CDNSKEY.  removing all CDS records can't be used since it
doesn't make any change at the parent as shown in steps 6 and 7.

Other than that, I think these examples are very clear, and I support
adding them as an appendix.

Best regards,
  Matthijs


 
 --
 JINMEI, Tatuya
 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On Apr 25, 2014, at 2:28 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote:

 Hi,
 
 On 04/24/2014 05:41 PM, 神明達哉 wrote:
 At Thu, 24 Apr 2014 07:55:52 +0200,
 Matthijs Mekking matth...@nlnetlabs.nl wrote:
 
 The child can also signal its desire to remove DS records by removing
 the corresponding records from the CDS/CDNSKEY RRset again.
 
 ...unless that would make the resulting CDS/CDNSKEY RRset empty.
 Otherwise it can contradict this one:
 
 Of course. I tried to rephrase it in four short lines. That does not
 mean that one line that stands alone is the absolute truth: you have to
 consider the complete context.
 
 
 If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
 this means there is no action to perform for the parent. Hence, this
 document does not support removing all DS records from the parent.
 
 I guess this discussions is essentially the same as what I asked a few
 months ago:
 http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html
 
 and while I thought revised versions of the draft were clear about
 this point, but the fact that we still have this discussion seems to
 suggest it's probably not sufficiently clear.  Perhaps the problem is
 that many of us already knows how it works and it's difficult for us
 to see how it could be interpreted by first-time readers.  So, while
 it may look redundant, it may help if we show a specific example of
 how the child adds/removes CDS/CDNSKEY and how it works at the parent:
 
 I am indeed pretty clear about how this should work and I think the
 draft reflects that. But indeed: there is nothing wrong with adding an
 appendix with some examples. Some remarks below:
 
 0. the child becomes signed from unsigned, tells the parent its
   DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
   of CDS/CDNSKEY:
   child.example. DS (for KSK1)
 1. the child adds the corresponding CDS in the child zone:
   child.example. DNSKEY (for KSK1)
   child.example. CDS (for KSK1)
 
 The child does not necessarily need to add the CDS now: The parent
 already has the correct DS RRset (step 0) and no rollover has happened
 since then.
 
 
 2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
   child zone:
   child.example. DNSKEY (for KSK1)
   child.example. DNSKEY (for KSK2)
   child.example. CDS (for KSK1)
   child.example. CDS (for KSK2)
 
 Depending on the type of rollover, the child might not want to add the
 CDS directly (Double-Signature KSK Rollover) or might want to add the
 CDS before adding the DNSKEY (Double-DS KSK Rollover).
 
 
 3. the parent notices or is notified of a change in the child, and
   finds there's a new CDS (for KSK2) that doesn't match its set of
   CDS, and adds a new DS corresponding to that one:
   child.example. DS (for KSK1)
   child.example. DS (for KSK2)
 4. the child confirms the DS and CDS are now synchronized, and removes
   the old DNSKEY (KSK1) and corresponding CDS:
   child.example. DNSKEY (for KSK2)
   child.example. CDS (for KSK2)
 
 You want to remove DNSKEY and CDS for KSK1 here.
 
 Again: The old CDS may be removed earlier, at the time of adding the CDS
 for KSK2 (Double-Signature) or later (Double-DS).
 
 
 5. the parent notices or is notified of a change in the child, and
   finds a CDS (for KSK1) that currently matches one of its DS's is
   now removed.  the parent removes the corresponding DS:
   child.example. DS (for KSK2)
 6. the child confirms the DS and CDS are now synchronized.  at this
   point, it MAY remove the remaining CDS for the reason explained in
   Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
   child.example. DNSKEY (for KSK2)
   (no CDS records)
 7. the parent notices the change in the child, but does nothing since
   there's no CDS record in the child:
   child.example. DS (for KSK2) ; still exist
 8. eventually the child might go unsigned again.  all of its DNSKEYs
   will be removed, but the child needs to tell the parent about the
   change and have them remove the DS records in some other way than
   CDS/CDNSKEY.  removing all CDS records can't be used since it
   doesn't make any change at the parent as shown in steps 6 and 7.
 
 Other than that, I think these examples are very clear, and I support
 adding them as an appendix.
 
 Best regards,
  Matthijs
 

I'm willing add an appendix that has Double DS KSK rollover to the appendix 
with reference to RFC6781 figure 7, as an example. 
I will think about the dual KSK example. 

Tim tell me if you DO NOT want this added to the document. 

Olafur 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

Olafur

Please add this. I'll get caught back up on the rest of this by the time warren 
returns from his walkabout. 

Sent from my Hi-Tech Gadget. 

 On Apr 25, 2014, at 6:48, Olafur Gudmundsson o...@ogud.com wrote:
 
 
 On Apr 25, 2014, at 2:28 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote:
 
 Hi,
 
 On 04/24/2014 05:41 PM, 神明達哉 wrote:
 At Thu, 24 Apr 2014 07:55:52 +0200,
 Matthijs Mekking matth...@nlnetlabs.nl wrote:
 
 The child can also signal its desire to remove DS records by removing
 the corresponding records from the CDS/CDNSKEY RRset again.
 
 ...unless that would make the resulting CDS/CDNSKEY RRset empty.
 Otherwise it can contradict this one:
 
 Of course. I tried to rephrase it in four short lines. That does not
 mean that one line that stands alone is the absolute truth: you have to
 consider the complete context.
 
 
 If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
 this means there is no action to perform for the parent. Hence, this
 document does not support removing all DS records from the parent.
 
 I guess this discussions is essentially the same as what I asked a few
 months ago:
 http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html
 
 and while I thought revised versions of the draft were clear about
 this point, but the fact that we still have this discussion seems to
 suggest it's probably not sufficiently clear.  Perhaps the problem is
 that many of us already knows how it works and it's difficult for us
 to see how it could be interpreted by first-time readers.  So, while
 it may look redundant, it may help if we show a specific example of
 how the child adds/removes CDS/CDNSKEY and how it works at the parent:
 
 I am indeed pretty clear about how this should work and I think the
 draft reflects that. But indeed: there is nothing wrong with adding an
 appendix with some examples. Some remarks below:
 
 0. the child becomes signed from unsigned, tells the parent its
  DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
  of CDS/CDNSKEY:
  child.example. DS (for KSK1)
 1. the child adds the corresponding CDS in the child zone:
  child.example. DNSKEY (for KSK1)
  child.example. CDS (for KSK1)
 
 The child does not necessarily need to add the CDS now: The parent
 already has the correct DS RRset (step 0) and no rollover has happened
 since then.
 
 
 2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
  child zone:
  child.example. DNSKEY (for KSK1)
  child.example. DNSKEY (for KSK2)
  child.example. CDS (for KSK1)
  child.example. CDS (for KSK2)
 
 Depending on the type of rollover, the child might not want to add the
 CDS directly (Double-Signature KSK Rollover) or might want to add the
 CDS before adding the DNSKEY (Double-DS KSK Rollover).
 
 
 3. the parent notices or is notified of a change in the child, and
  finds there's a new CDS (for KSK2) that doesn't match its set of
  CDS, and adds a new DS corresponding to that one:
  child.example. DS (for KSK1)
  child.example. DS (for KSK2)
 4. the child confirms the DS and CDS are now synchronized, and removes
  the old DNSKEY (KSK1) and corresponding CDS:
  child.example. DNSKEY (for KSK2)
  child.example. CDS (for KSK2)
 
 You want to remove DNSKEY and CDS for KSK1 here.
 
 Again: The old CDS may be removed earlier, at the time of adding the CDS
 for KSK2 (Double-Signature) or later (Double-DS).
 
 
 5. the parent notices or is notified of a change in the child, and
  finds a CDS (for KSK1) that currently matches one of its DS's is
  now removed.  the parent removes the corresponding DS:
  child.example. DS (for KSK2)
 6. the child confirms the DS and CDS are now synchronized.  at this
  point, it MAY remove the remaining CDS for the reason explained in
  Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
  child.example. DNSKEY (for KSK2)
  (no CDS records)
 7. the parent notices the change in the child, but does nothing since
  there's no CDS record in the child:
  child.example. DS (for KSK2) ; still exist
 8. eventually the child might go unsigned again.  all of its DNSKEYs
  will be removed, but the child needs to tell the parent about the
  change and have them remove the DS records in some other way than
  CDS/CDNSKEY.  removing all CDS records can't be used since it
  doesn't make any change at the parent as shown in steps 6 and 7.
 
 Other than that, I think these examples are very clear, and I support
 adding them as an appendix.
 
 Best regards,
 Matthijs
 
 I'm willing add an appendix that has Double DS KSK rollover to the appendix 
 with reference to RFC6781 figure 7, as an example. 
 I will think about the dual KSK example. 
 
 Tim tell me if you DO NOT want this added to the document. 
 
Olafur 
 
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Thu, 24 Apr 2014 07:55:52 +0200,
Matthijs Mekking matth...@nlnetlabs.nl wrote:

 The child can also signal its desire to remove DS records by removing
 the corresponding records from the CDS/CDNSKEY RRset again.

...unless that would make the resulting CDS/CDNSKEY RRset empty.
Otherwise it can contradict this one:

 If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
 this means there is no action to perform for the parent. Hence, this
 document does not support removing all DS records from the parent.

I guess this discussions is essentially the same as what I asked a few
months ago:
http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html

and while I thought revised versions of the draft were clear about
this point, but the fact that we still have this discussion seems to
suggest it's probably not sufficiently clear.  Perhaps the problem is
that many of us already knows how it works and it's difficult for us
to see how it could be interpreted by first-time readers.  So, while
it may look redundant, it may help if we show a specific example of
how the child adds/removes CDS/CDNSKEY and how it works at the parent:

0. the child becomes signed from unsigned, tells the parent its
   DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
   of CDS/CDNSKEY:
   child.example. DS (for KSK1)
1. the child adds the corresponding CDS in the child zone:
   child.example. DNSKEY (for KSK1)
   child.example. CDS (for KSK1)
2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
   child zone:
   child.example. DNSKEY (for KSK1)
   child.example. DNSKEY (for KSK2)
   child.example. CDS (for KSK1)
   child.example. CDS (for KSK2)
3. the parent notices or is notified of a change in the child, and
   finds there's a new CDS (for KSK2) that doesn't match its set of
   CDS, and adds a new DS corresponding to that one:
   child.example. DS (for KSK1)
   child.example. DS (for KSK2)
4. the child confirms the DS and CDS are now synchronized, and removes
   the old DNSKEY (KSK1) and corresponding CDS:
   child.example. DNSKEY (for KSK2)
   child.example. CDS (for KSK2)
5. the parent notices or is notified of a change in the child, and
   finds a CDS (for KSK1) that currently matches one of its DS's is
   now removed.  the parent removes the corresponding DS:
   child.example. DS (for KSK2)
6. the child confirms the DS and CDS are now synchronized.  at this
   point, it MAY remove the remaining CDS for the reason explained in
   Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
   child.example. DNSKEY (for KSK2)
   (no CDS records)
7. the parent notices the change in the child, but does nothing since
   there's no CDS record in the child:
   child.example. DS (for KSK2) ; still exist
8. eventually the child might go unsigned again.  all of its DNSKEYs
   will be removed, but the child needs to tell the parent about the
   change and have them remove the DS records in some other way than
   CDS/CDNSKEY.  removing all CDS records can't be used since it
   doesn't make any change at the parent as shown in steps 6 and 7.

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jacques Latour]

The Child may also remove old  keys, but this document does not support 
removing all keys.
When the Parent DS is in-sync with the CDS / CDNSKEY resource records, the 
Child DNS Operator MAY delete the CDS / CDNSKEY record(s);

Read the whole thing a couple of times and it's not clear to me how to remove 
one or more DS? Once in-sync, If the parental agent polling/mechanism detect 
a CDS for an existing DS, or a CDNSKEY for a matching DS, then you remove the 
DS but not if it's the last one? Right? Or there's a ADD/DELETE parameter to 
the proposed CDS and CDNSKEY resource records to instruct the parental agent on 
the type of operation to perform?

Jack

 -Original Message-
 From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley
 Sent: April-21-14 9:34 AM
 To: Warren Kumari
 Cc: dnsop; Paul Hoffman
 Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-
 delegation-trust-maintainance
 
 
 On 16 Apr 2014, at 8:02, Warren Kumari war...@kumari.net wrote:
 
  I think I made it even clearer:
  The first time a DNS operator signs a zone, they need to communicate
  the keying material to their parent through some out-of-band method to
  complete the chain of trust. Depending on the desires of the parent,
  the child might send their DNSKEY record, a DS record, or both.
 
 I don't think you mean the first time a DNS operator signs a zone. You're
 making an assumption that a zone, once signed, will never be unsigned. In
 fact, a zone can be signed, then unsigned, any number of times.
 
 Whenever a zone's insecure delegation is replaced by a secure delegation,
 the DNS operator needs to communicate the keying material...
 
 
 Joe
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

Hi Jacques,

On 04/23/2014 06:57 PM, Jacques Latour wrote:
 The Child may also remove old  keys, but this document does not
 support removing all keys. When the Parent DS is in-sync with the
 CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the
 CDS / CDNSKEY record(s);
 
 Read the whole thing a couple of times and it's not clear to me how
 to remove one or more DS? Once in-sync, If the parental agent

By removing the corresponding CDS/CDNSKEY from the CDS/CDNSKEY RRset.

 polling/mechanism detect a CDS for an existing DS, or a CDNSKEY for a
 matching DS, then you remove the DS but not if it's the last one?

No: The parent would never remove a DS when it sees a CDS/CDNSKEY for an
existing DS.

 Right? Or there's a ADD/DELETE parameter to the proposed CDS and
 CDNSKEY resource records to instruct the parental agent on the type
 of operation to perform?

Let me try to rephrase:

The child can signal its desire to add DS records by publishing
corresponding records in the CDS/CDNSKEY RRset.

The child can also signal its desire to remove DS records by removing
the corresponding records from the CDS/CDNSKEY RRset again.

If the CDS/CDNSKEY RRset is in-sync with the DS RRset at the parent, the
child MAY remove the CDS/CDNSKEY RRset from its zone.

If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
this means there is no action to perform for the parent. Hence, this
document does not support removing all DS records from the parent.

Best regards,
  Matthijs

 
 Jack
 
 -Original Message- From: DNSOP
 [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley Sent:
 April-21-14 9:34 AM To: Warren Kumari Cc: dnsop; Paul Hoffman 
 Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop- 
 delegation-trust-maintainance
 
 
 On 16 Apr 2014, at 8:02, Warren Kumari war...@kumari.net wrote:
 
 I think I made it even clearer: The first time a DNS operator
 signs a zone, they need to communicate the keying material to
 their parent through some out-of-band method to complete the
 chain of trust. Depending on the desires of the parent, the child
 might send their DNSKEY record, a DS record, or both.
 
 I don't think you mean the first time a DNS operator signs a
 zone. You're making an assumption that a zone, once signed, will
 never be unsigned. In fact, a zone can be signed, then unsigned,
 any number of times.
 
 Whenever a zone's insecure delegation is replaced by a secure
 delegation, the DNS operator needs to communicate the keying
 material...
 
 
 Joe ___ DNSOP mailing
 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
 
 ___ DNSOP mailing list 
 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 16 Apr 2014, at 8:02, Warren Kumari war...@kumari.net wrote:

 I think I made it even clearer:
 The first time a DNS operator signs a zone, they need to communicate
 the keying material to their parent through some out-of-band method to
 complete the chain of trust. Depending on the desires of the parent,
 the child might send their DNSKEY record, a DS record, or both.

I don't think you mean the first time a DNS operator signs a zone. You're 
making an assumption that a zone, once signed, will never be unsigned. In fact, 
a zone can be signed, then unsigned, any number of times.

Whenever a zone's insecure delegation is replaced by a secure delegation, the 
DNS operator needs to communicate the keying material...


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

On 04/16/2014 06:40 PM, Warren Kumari wrote:
 On Wed, Apr 16, 2014 at 9:19 AM, Dan York y...@isoc.org wrote:

 On Apr 16, 2014, at 8:02 AM, Warren Kumari war...@kumari.net
  wrote:

 I think I made it even clearer:
 The first time a DNS operator signs a zone, they need to communicate
 the keying material to their parent through some out-of-band method to
 complete the chain of trust. Depending on the desires of the parent,
 the child might send their DNSKEY record, a DS record, or both.

 Good?


 Looks good to me.The whole document is looking very good.  I've been
 reading the conversation and initially had some concerns but others already
 addressed the points (and so I felt no need to add to the queue of
 messages).
 
 ... and I got an off-list comment pointing out that:
 Section 6.1
  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).
 
 But in section 4.1 you say
o  Signer: MUST be signed with a key that is represented in both the
current DNSKEY and DS RRset's.
 
 One of the two must be reworded.
 
 Doh! So, I have updated the Signer rule to be:
 o  Signer: MUST be signed with a key that is represented in both the
 current DNSKEY and DS RRset's (unless the parent validates the
 CDS / CDNSKEY though some other means (see Section 6.1 and the
 Security Considerations.))
 
 Any (major) objections?

Yes:)

The comment in 6.1 is meant for a way to use this technique for initial
enrollment. So I would rather see that the rewording in 4.1 also
reflects that: I don't want the regular maintenance to be susceptible to
'other means validation'. Suggestion:

(unless the parent uses the CDS / CDNSKEY RRset for initial enrollment,
in that case the parent validates the CDS / CDNSKEY though some other
means (see Section 6.1 and the Security Considerations.))

Best regards,
  Matthijs

 
 This time for sure,
 W
 
 
 

 Dan

 --
 Dan York
 Senior Content Strategist, Internet Society
 y...@isoc.org   +1-802-735-1624
 Jabber: y...@jabber.isoc.org
 Skype: danyork   http://twitter.com/danyork

 http://www.internetsociety.org/deploy360/


 
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop
 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, Apr 17, 2014 at 4:46 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote:
 On 04/16/2014 06:40 PM, Warren Kumari wrote:
 On Wed, Apr 16, 2014 at 9:19 AM, Dan York y...@isoc.org wrote:

 On Apr 16, 2014, at 8:02 AM, Warren Kumari war...@kumari.net
  wrote:

 I think I made it even clearer:
 The first time a DNS operator signs a zone, they need to communicate
 the keying material to their parent through some out-of-band method to
 complete the chain of trust. Depending on the desires of the parent,
 the child might send their DNSKEY record, a DS record, or both.

 Good?


 Looks good to me.The whole document is looking very good.  I've been
 reading the conversation and initially had some concerns but others already
 addressed the points (and so I felt no need to add to the queue of
 messages).

 ... and I got an off-list comment pointing out that:
 Section 6.1
  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).

 But in section 4.1 you say
o  Signer: MUST be signed with a key that is represented in both the
current DNSKEY and DS RRset's.

 One of the two must be reworded.

 Doh! So, I have updated the Signer rule to be:
 o  Signer: MUST be signed with a key that is represented in both the
 current DNSKEY and DS RRset's (unless the parent validates the
 CDS / CDNSKEY though some other means (see Section 6.1 and the
 Security Considerations.))

 Any (major) objections?

 Yes:)

 The comment in 6.1 is meant for a way to use this technique for initial
 enrollment. So I would rather see that the rewording in 4.1 also
 reflects that: I don't want the regular maintenance to be susceptible to
 'other means validation'. Suggestion:

 (unless the parent uses the CDS / CDNSKEY RRset for initial enrollment,
 in that case the parent validates the CDS / CDNSKEY though some other
 means (see Section 6.1 and the Security Considerations.))

Oooh! Nice.
I was unable to come up with a succinct way of saying that. Changed.
I also fixed a typo / thinko in the Acknowledgements section.

*This* time for sure,
W





 Best regards,
   Matthijs


 This time for sure,
 W




 Dan

 --
 Dan York
 Senior Content Strategist, Internet Society
 y...@isoc.org   +1-802-735-1624
 Jabber: y...@jabber.isoc.org
 Skype: danyork   http://twitter.com/danyork

 http://www.internetsociety.org/deploy360/



 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jaap Akkerhuis]

 When a DNS operator first signs their zone, they need to communicate their
 keying material to their parent through some out-of-band method to 
complete



And changing opening sentence to:

The first time a DNS operator signs the zone, they need to
communicate the keying ...

Make it even more clear.

jaap (nitpicking mode)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Wed, Apr 16, 2014 at 3:34 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote:

  When a DNS operator first signs their zone, they need to communicate 
 their
  keying material to their parent through some out-of-band method to 
 complete



 And changing opening sentence to:

 The first time a DNS operator signs the zone, they need to
 communicate the keying ...

 Make it even more clear.

Thank you.
I think I made it even clearer:
The first time a DNS operator signs a zone, they need to communicate
the keying material to their parent through some out-of-band method to
complete the chain of trust. Depending on the desires of the parent,
the child might send their DNSKEY record, a DS record, or both.

Good?
W



 jaap (nitpicking mode)

 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dan York]

On Apr 16, 2014, at 8:02 AM, Warren Kumari 
war...@kumari.netmailto:war...@kumari.net
 wrote:

I think I made it even clearer:
The first time a DNS operator signs a zone, they need to communicate
the keying material to their parent through some out-of-band method to
complete the chain of trust. Depending on the desires of the parent,
the child might send their DNSKEY record, a DS record, or both.

Good?

Looks good to me.The whole document is looking very good.  I've been 
reading the conversation and initially had some concerns but others already 
addressed the points (and so I felt no need to add to the queue of messages).

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Wed, Apr 16, 2014 at 9:19 AM, Dan York y...@isoc.org wrote:

 On Apr 16, 2014, at 8:02 AM, Warren Kumari war...@kumari.net
  wrote:

 I think I made it even clearer:
 The first time a DNS operator signs a zone, they need to communicate
 the keying material to their parent through some out-of-band method to
 complete the chain of trust. Depending on the desires of the parent,
 the child might send their DNSKEY record, a DS record, or both.

 Good?


 Looks good to me.The whole document is looking very good.  I've been
 reading the conversation and initially had some concerns but others already
 addressed the points (and so I felt no need to add to the queue of
 messages).

... and I got an off-list comment pointing out that:
Section 6.1
 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).

But in section 4.1 you say
   o  Signer: MUST be signed with a key that is represented in both the
   current DNSKEY and DS RRset's.

One of the two must be reworded.

Doh! So, I have updated the Signer rule to be:
o  Signer: MUST be signed with a key that is represented in both the
current DNSKEY and DS RRset's (unless the parent validates the
CDS / CDNSKEY though some other means (see Section 6.1 and the
Security Considerations.))

Any (major) objections?

This time for sure,
W




 Dan

 --
 Dan York
 Senior Content Strategist, Internet Society
 y...@isoc.org   +1-802-735-1624
 Jabber: y...@jabber.isoc.org
 Skype: danyork   http://twitter.com/danyork

 http://www.internetsociety.org/deploy360/



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Tue, Apr 15, 2014 at 4:23 AM, Antoin Verschuren
antoin.verschu...@sidn.nl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 op 14-04-14 21:18, Warren Kumari schreef:

 Just checking -- do you want any action *on this doc*? I *think*
 that we are generic/non-prescriptive enough that you can
 implement whatever policy you want...

 Yes, like I said, I would like to have this line deleted in section 6:

   A parent MUST NOT perform a consistency check between CDS and
CDNSKEY (other than for informational / debugging use) resource
records.

 That's not protocol, but prescriptive language that a parent is
 disallowed to have a policy to verify the records.

Ah. Sorry, was not intentionally ignoring you, I just missed where you
were meaning...


 I also think the line just above that:

   The parent MUST choose to accept either CDS or CDNSKEY resource
records (based upon local policy), and MUST NOT expect there to be
both.

 is mixing up 2 things:
 - -What the parent -accepts-
 - -What the parent -uses- when both are present.

 I think it's perfectly fine for a parent to accept both, but it must
 state which it will use when it sees both in the zone to manage
 expectancy.

 So suggested text to replace that with:

 The parent MUST choose to use either CDNSKEY or CDS resource records
 as their default updating mechanism.
 The parent MAY only accept either CDNSKEY or CDS, but it MAY also
 accept both, so it can use the other in the absence of the default
 updating mechanism, but it MUST NOT expect there to be both.

DONE!
Nice, thanks for the text...

W




 - --
 Antoin Verschuren

 Technical Policy Advisor SIDN
 Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

 P: +31 26 3525500  M: +31 6 23368970
 Mailto: antoin.verschu...@sidn.nl
 XMPP: antoin.verschu...@jabber.sidn.nl
 HTTP://www.sidn.nl/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iQEcBAEBAgAGBQJTTOyRAAoJEDqHrM883Agn5JYH+gIEg2aLAcaDTvJfa5I23vAY
 rGyiBmT0oL9AmihDC1nNnFMascqev70Uu3txc1bKYOnhrLFCzqUwudcEnu4l1ha8
 JdQv8GfotXdwRHCuYxxEtn22J8XOtH+bCSVfvZlirJtCW3jCLQqNq3rZHOd1xGs6
 anocAxV5Sm6+btkrmxXCIMktt92uG4FXEGVgSaPxUO57K6+j5hVxS71VpGid2r77
 iqx3f0xl9p6AjKwJz2c0la1CuE/+mG0/8uH6m/rSQXfB/nYDzDPa9IO74baEjRkO
 5WOxVJ7WBiFfpGX6UNdN9ui+dixHqn0ugkOAWz89Pu0k7fbaEzI1Z4nME0dBhvU=
 =H1BY
 -END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

This looks greatly improved from the -03 that started the WG Last Call. It 
clears almost all of my concerns, particularly about the overly-loose language.

There is still one assumption being made of the reader that I think can cleanly 
be cleared up. The first paragraph of the introduction says:

   When a DNS operator first signs their zone, they need to communicate
   their DS record(s) (or DNSKEY(s)) to their parent through some out-
   of-band method to complete the chain of trust.

I think the concept of what is being told to the parent would be much clearer 
as:

   When a DNS operator first signs their zone, they need to communicate their
   keying material to their parent through some out-of-band method to complete
   the chain of trust. Depending on the desires of the parent, the child might
   send their DNSKEY record, a DS record, or both.

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On Apr 15, 2014, at 8:06 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:

 This looks greatly improved from the -03 that started the WG Last Call. It 
 clears almost all of my concerns, particularly about the overly-loose 
 language.
 
 There is still one assumption being made of the reader that I think can 
 cleanly be cleared up. The first paragraph of the introduction says:
 
   When a DNS operator first signs their zone, they need to communicate
   their DS record(s) (or DNSKEY(s)) to their parent through some out-
   of-band method to complete the chain of trust.
 
 I think the concept of what is being told to the parent would be much clearer 
 as:
 
   When a DNS operator first signs their zone, they need to communicate their
   keying material to their parent through some out-of-band method to complete
   the chain of trust. Depending on the desires of the parent, the child might
   send their DNSKEY record, a DS record, or both.


I agree this text is much better. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Tuesday, April 15, 2014, Paul Hoffman paul.hoff...@vpnc.org wrote:

 This looks greatly improved from the -03 that started the WG Last Call. It
 clears almost all of my concerns, particularly about the overly-loose
 language.

 There is still one assumption being made of the reader that I think can
 cleanly be cleared up. The first paragraph of the introduction says:

When a DNS operator first signs their zone, they need to communicate
their DS record(s) (or DNSKEY(s)) to their parent through some out-
of-band method to complete the chain of trust.

 I think the concept of what is being told to the parent would be much
 clearer as:

When a DNS operator first signs their zone, they need to communicate
 their
keying material to their parent through some out-of-band method to
 complete
the chain of trust. Depending on the desires of the parent, the child
 might
send their DNSKEY record, a DS record, or both.



Looks good, thank you for the text, I'll integrate it tomorrow.

W



 --Paul Hoffman
 ___
 DNSOP mailing list
 DNSOP@ietf.org javascript:;
 https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Antoin Verschuren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

op 12-04-14 00:06, Warren Kumari schreef:
 The parent should use whichever one they choose, but MUST NOT query
 for both and perform consistency checks between the CDS and CDNSKEY
 records.
 
 A parent MUST NOT perform a consistency check between CDS and
 CDNSKEY (other than for informational / debugging use).

I want this part deleted. Whether or not parents do DNS protocol
verification is local policy and up to the parent. While pedantic to
some, it may serve a local need to others. An RFC is not the place to
enforce a specific local policy to parents that annoys only a certain
part of the DNS community. Just state how the protocol works, but do
not state it may or may not be verified. This protocol does not only
work for TLD registries, but especially also lower down the tree, and
I know protocol verification is a reasonable requirement there for
certain use cases. If you're not happy with that local policy, choose
a different parent or complain to your local parent, not the IETF.

You can publish a CDNSKEY or CDS or both.
If you publish both, they MUST match.

I can live with this line (watch the MAY):

The parent MAY choose to only accept either CDS or CDNSKEY records
(based upon local policy), but MUST NOT expect there to be both.

Because it is perfectly sane from a protocol perspective to only have
one type and not the other if you know the local policy of your parent
or have a preference as a child in case they accept both.

Since CDNSKEY and CDS MUST match, the parent can:
- -accept CDNSKEY and only receive CDNSKEY
- -accept CDS and only receive CDS
- -accept both and have a preference for CDNSKEY if they receive both
- -accept both and have a preference for CDS if they receive both
- -accept both and use CDNSKEY if they only receive CDNSKEY
- -accept both and use CDS if they only receive CDS
- -accept CDNSKEY and not verify if they receive both
- -accept CDS and not verify is they receive both
- -accept CDNSKEY and verify if they recieve both
- -accept CDS and verify if they receive both
- -.



- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschu...@sidn.nl
XMPP: antoin.verschu...@jabber.sidn.nl
HTTP://www.sidn.nl/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTS6nlAAoJEDqHrM883Agnxt0H/iuHR1uKJA4NbAnF6MFHrl3r
DF4q4q8iwKtw+UF7FesilqvrnlU8cn9wTODhWLqPI+DZWKPYEZ/PnxX8FJs0FvfF
YlS6WIsvLT6+7tx8+hMFrnCA322WNx/TM9bkB1oPRGlyttEZmRvCTUwbhx3aMr/0
g8cihBANsHzJC6miFVN/MRSxQmw11qNiMc52QxxGMk6KPfeAGhOyHQ00FDEj0Ntg
zrQuIKtI+z3EWqZfB7jl3i4Biq0idCMOJg2UZcIZH/NquT44Wv6q4eylNV36usZc
CCtQOMJajjm3xow1R3F6iTjsVS+vBuWGagL+jVItOo3YfzIrm5Di/k9bbQ0B7hw=
=5haO
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Antoin Verschuren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

op 10-04-14 21:54, Patrik Fältström schreef:

 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.

While I agree with you some (TLD) parents are sometimes too pedantic,
it may serve a need for parents to refuse certain use cases under
their parenthood. If the rules are stupid, complain to the parent if
you want to be his child.

 Parent should not control the child.

I don't agree you can put it that generic. Some parents only want
specific use under their tree, and you cannot force a parent to grant
you a use case you want. While I agree with you some parents want to
control their children too much, and hence have silly rules that don't
match the use case they want to accommodate, it's not always the case.
Don't throw away the child with the bathwater.

Let me give you a use case where this may be clear.
Suppose I want to set up a network of probes under a parent
probenetwork.example.com. Every probe gets a registration, but for
the probenetwork to work, every delegation MUST do DNSSEC with an
algoritm the probe architecture can handle and know the whereabouts of
every other probe. Every probe handles it's own delegation so queries
over the network requires the zones to contain specific records the
probes use. So my local policy is to only allow delegations for
certain DNSSEC algorithms, and every delegated zone MUST contain a LOC
record.
In order not to disturb the running probe network, I only accept new
delegations after I verify the child zone for that.

Another example may be that as a parent, we do not want too short
TTL's on the child's NS RRset because our infrastructure is hit with
more queries that are useless with our zone's publication frequency.
And we don't want too long TTL's as a countermeasure against ghost
domains misused by botnets. Now the botnet herders may be against that
policy, but it's our choice as a parent not to accommodate that use
case in our tree unless someone convinces us there's a legitimate
other use case that cannot live with those rules.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschu...@sidn.nl
XMPP: antoin.verschu...@jabber.sidn.nl
HTTP://www.sidn.nl/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTS8HQAAoJEDqHrM883Agn8XYIANEHTXRmoAgK0nFN+UXLcjY3
SU8c9x0C2ZIgVFpPm1jIyyetFhzVgtHh6IzJb0BRINziRYYaXkR0sNxC0feCpboP
sv4nPBw3JkY24rZ6xFJ9O+vSA3TLujp9JlgudZLAPVx/g2LuGeO7jwGXssF95I5F
Uv9eFOLH6Nul3KVynN6osRaE6fgHyaFppOb/SvkCVRwpccyrGTH+jQzlHhdhL9rv
ra+VG5G3pDrRND4LcRAHpev14QYhZejmyXsf4scIy/fh4SSCvUZ5wuwhTbMWPMtG
ocVAZFqibdVZWJ1E/xDxSXSqqXU3lGCuDHGvFe8P+fZcUO5lHuPjBRK3NnSimag=
=khPI
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Mon, Apr 14, 2014 at 7:09 AM, Antoin Verschuren
antoin.verschu...@sidn.nl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 op 10-04-14 21:54, Patrik Fältström schreef:

 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.

 While I agree with you some (TLD) parents are sometimes too pedantic,
 it may serve a need for parents to refuse certain use cases under
 their parenthood. If the rules are stupid, complain to the parent if
 you want to be his child.

 Parent should not control the child.

 I don't agree you can put it that generic. Some parents only want
 specific use under their tree, and you cannot force a parent to grant
 you a use case you want. While I agree with you some parents want to
 control their children too much, and hence have silly rules that don't
 match the use case they want to accommodate, it's not always the case.
 Don't throw away the child with the bathwater.

 Let me give you a use case where this may be clear.
 Suppose I want to set up a network of probes under a parent
 probenetwork.example.com. Every probe gets a registration, but for
 the probenetwork to work, every delegation MUST do DNSSEC with an
 algoritm the probe architecture can handle and know the whereabouts of
 every other probe. Every probe handles it's own delegation so queries
 over the network requires the zones to contain specific records the
 probes use. So my local policy is to only allow delegations for
 certain DNSSEC algorithms, and every delegated zone MUST contain a LOC
 record.
 In order not to disturb the running probe network, I only accept new
 delegations after I verify the child zone for that.

 Another example may be that as a parent, we do not want too short
 TTL's on the child's NS RRset because our infrastructure is hit with
 more queries that are useless with our zone's publication frequency.
 And we don't want too long TTL's as a countermeasure against ghost
 domains misused by botnets. Now the botnet herders may be against that
 policy, but it's our choice as a parent not to accommodate that use
 case in our tree unless someone convinces us there's a legitimate
 other use case that cannot live with those rules.

Just checking -- do you want any action *on this doc*? I *think* that
we are generic/non-prescriptive enough that you can implement whatever
policy you want...
If you'd like something additional (probably in Section 6.2) saying
something like Acting on CDS/CDNSKEY records may be subject to local
policy or something, please help by providing text...

I *think* that we are generic enough that this is covered, but...

W


 - --
 Antoin Verschuren

 Technical Policy Advisor SIDN
 Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

 P: +31 26 3525500  M: +31 6 23368970
 Mailto: antoin.verschu...@sidn.nl
 XMPP: antoin.verschu...@jabber.sidn.nl
 HTTP://www.sidn.nl/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iQEcBAEBAgAGBQJTS8HQAAoJEDqHrM883Agn8XYIANEHTXRmoAgK0nFN+UXLcjY3
 SU8c9x0C2ZIgVFpPm1jIyyetFhzVgtHh6IzJb0BRINziRYYaXkR0sNxC0feCpboP
 sv4nPBw3JkY24rZ6xFJ9O+vSA3TLujp9JlgudZLAPVx/g2LuGeO7jwGXssF95I5F
 Uv9eFOLH6Nul3KVynN6osRaE6fgHyaFppOb/SvkCVRwpccyrGTH+jQzlHhdhL9rv
 ra+VG5G3pDrRND4LcRAHpev14QYhZejmyXsf4scIy/fh4SSCvUZ5wuwhTbMWPMtG
 ocVAZFqibdVZWJ1E/xDxSXSqqXU3lGCuDHGvFe8P+fZcUO5lHuPjBRK3NnSimag=
 =khPI
 -END PGP SIGNATURE-

 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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?

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.

 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.


 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 

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

[Patrik Fältström]

On 11 apr 2014, at 11:36, Matthijs Mekking matth...@nlnetlabs.nl wrote:

 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 ;)

Exactly, thats why I think we should say MUST (but explain what we mean with 
it).

   Patrik



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Antoin Verschuren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

op 10-04-14 21:54, Patrik Fältström schreef:
 On 10 apr 2014, at 18:34, Warren Kumari war...@kumari.net wrote:

 If we were to *require* that they match, what happens in the
 case where they *don't*? Do we fail the keyroll? That seems
 suboptimal. Do we throw a log message? No one will see it... If
 you consume CDS (or CDNSKEY), you simply ignore the other one --
 it's not really relevant to you, and no good can come from
 looking at it. Ignorance is bliss...
 
 Understood.
 
 But I think you must explain what the parent should do.
 
 Fetch CDS and CDNSKEY, look at them and see that they lead to
 different result. What should then the parent do? Pick CDS or
 CDNSKEY, or pick one by random, or...?

What should a parent do when it fetches a CDS or CDNSKEY and the Rdata
does not make sense at all on its own? f.e. the Rdata does not parse
as a DNSKEY or DS? If a child puts a CDS in his zone where the Rdata
says this is not a key at all, should I publish that?

I think since this is a protocol definition, CDS and CDNSKEY MUST
match. What a parent should do when the protocol is violated is I
guess an implementation issue, BCP, or perhaps even local policy. A
parent may only look at CDNSKEY or CDS or both. Saying they MUST match
when they are both in the zone does not state anything on what the
parent should do when they don't, same as when the Rdata is rubish.

I would personally accept a CDNSKEY that does not match a CDS, knowing
that the child may be in trouble when I change my policy in accepting
CDS in the future. But that's the price the child pays for violating
the protocol. I don't see any use case or excuse for the CDNSKEY and
CDS not matching -if- they are both in the zone.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschu...@sidn.nl
XMPP: antoin.verschu...@jabber.sidn.nl
HTTP://www.sidn.nl/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTR73uAAoJEDqHrM883Agn5JgH/RYCUHkgNCcUW+ufE0eVnLHJ
SocZtLncRqt4340MvFzxo5Fsdcmn+96ftF+Tvk7ixLZy80HX5OPDyW6YCOu2J9oR
PLcIo3Nbps4Y9Tn8fxYsp1pcVD1e8JuI7uUFhzX86h9HjYxOPIT+nGaFe3PKn92n
v5cuIeWiYoPCnGxzDcKYtuZry6PX8oY93vuvDfBwY2lr3DPHYmpV0paQ9hfZPSoG
8enurd9ENrZ7TBaDYg1FXoHc9rFP94v7LLPHS0yr44t4lJiBfY8k/TC200w8f8H8
8JmNIdcRcz3CW190ZEC9QOfHAVzJK8tlCLvOT2fCex3kRPdaY5smcsqo43cZWD0=
=Hh2a
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

Hi,

I support publication of this document, but I agree that some things
should be improved before its ready to do so. Mainly the RFC2119
language (raised by Patrik), the rule of removing the CDS/CDNSKEY RRset
at the child and missing/no clear guidelines to prevent DS flapping.

Besides some nits which I will send the editors off-list, here are my
comments:


2.1.  DNS delegations

   But this
   fails to meet some operating needs, including the child having no
   influence what DS digest algorithms are used and DS records can only
   be published for keys that are in the DNSKEY RRset.

The reason why that is bad is because it then would not be compatible
with the Double-DS key rollover method. Perhaps it is good to add that
explicitly.


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 SHOULD remove all CDS records from the zone.

I would rather see MAY here, having the retain RRset be the normal case,
agreeing with Patrik Faltstrom earlier comments.


   Following acceptance rules are placed on the CDS / CDNSKEY records as
   follows:

   o  Signer: MUST be signed with a key that is represented in both the
  current DNSKEY and DS RRset's.

In other words: The CDS and CDNSKEY RRsets MUST be signed with an active
KSK. This introduces new tasks for keys that have the role of KSK. In
current software, a KSK only signs the DNSKEY RRset. Basically, with
this rule you are extending the role to also sign the CDS and CDNSKEY
RRsets. I am fine with that, they all are there for the same main
purpose: maintaining the chain of trust. But I think this can be
mentioned more explicitly in the document.

Now do we also require the ZSK have signing these RRsets? I don't think
so. So also the signing rules for ZSKs can be adjusted.


5.  Child's CDS / CDNSKEY Publication

   A child MAY publish both CDS and CDNSKEY.  If a child chooses to
   publish both, it MUST attempt to maintain consistency (a matching CDS
   for each CDNSKEY).

Another weak RFC2119 requirement: MUST attempt. I think you have to get
rid of the word attempt.


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.

Patrik already asked what the RFC2119 equivalent for 'good idea' would
be. Perhaps this is a SHOULD. This way the parental agent can be more
sure of things being in-sync at the child name servers.

   The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
   RRset do not overwrite newer versions.  This MAY be accomplished by
   checking that the signature inception in the RRSIG for CDS / CDNSKEY
   is newer and/or the serial number on the child's SOA is greater.
   This may require the Parental Agent to maintain some state
   information.

Or use the good idea from above, to prevent maintaining state.


Best regards,
  Matthijs




On 04/02/2014 09:07 PM, Tim Wicinski wrote:
 Greetings,
 
 This is the starting of the WGLC on Automating DNSSEC delegation trust
 maintenance.  This was briefly covered in London and these are ready for
 WGLC.   The current versions of this documents can be found here:
 

 https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

 http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt
 
 
 We'll have a 2 week period for comments, closing on April 16th, 2014. 
 
 thanks
 tim
 
 
 
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop
 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Patrik Fältström]

On 11 apr 2014, at 12:03, Antoin Verschuren antoin.verschu...@sidn.nl wrote:

 I think since this is a protocol definition, CDS and CDNSKEY MUST
 match. What a parent should do when the protocol is violated is I
 guess an implementation issue, BCP, or perhaps even local policy. A
 parent may only look at CDNSKEY or CDS or both. Saying they MUST match
 when they are both in the zone does not state anything on what the
 parent should do when they don't, same as when the Rdata is rubish.

I support this. This makes possible for parents to decide themselves whether:

1. They only fetch CDNSKEY and will not fetch CDS
2. They only fetch CDS and will not fetch CDNSKEY
3. They fetch CDNSKEY first, and then CDS if CDNSKEY does not exist
4. They fetch CDS and first, and then CDNSKEY if CDS does not exist
5. They fetch both CDS and CDNSKEY and will only pick data if the two are the 
same
6, ...

Etc.

If that is not the case, i.e. that the wg want a specific algorithm, then that 
should be explicit.

Unless we have an algorithm, then I support the fact that according to the 
protocol, they MUST result in the same result, as the parent can choose what 
algorithm they use.

   Patrik





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, Apr 10, 2014 at 3:54 PM, Patrik Fältström p...@frobbit.se wrote:
 On 10 apr 2014, at 18:34, Warren Kumari war...@kumari.net wrote:

 Because of this, I do not mind having some extra words here, like:

 This proposal do not include all operations needed for maintenance of 
 DNSSEC key material, specifically introduction and complete removal of all 
 keys. Because of this alternate communications mechanisms must always 
 exist, which might introduce extra complexity.

 DONE.

 Thanks!


No worries, we aim to please!


 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.

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.


 2.2.2.  DNSSEC key change process

   After a Child DNS operator first signs the zone, there is a need to
   interact with the Parent, for example via the delegation account
   interface, to upload / paste-in the zone's DS information.  The
   action of logging in through the delegation account user interface
   authenticates that the user is authorized to change delegation
   information for the child published in the parent zone.  In the case
   where the Child DNS Operator does not have access to the
   registration account, the Child needs to perform the action.

   At a later date, the Child DNS Operator may want to publish a new DS
   record in the parent, either because they are rolling keys, or
   because they want to publish a stand-by key.  This involves
   performing the same process as before.  Furthermore when this is a
   manual process with cut and paste, operational mistakes will happen
   -- or worse, the update action is not performed at all.

 Should it not be mentioned here that child might want to remove all keys as 
 well? I mean, if this is supposed to be a complete list of potential 
 operations the child is interested in?

 I see in fact (with some special cases):

 A. Introduction of new keys

 A.1. Introduction when old keys exists and can be used

 A.2. Introduction when no old keys can be used (because they can not be 
 trusted or because no such exists)

 B. Removal of keys

 B.1. Removal of old keys when at least one key still remains in the RRSet 
 of zone apex

 B.2. Removal of last key from the RRSet of the zone apex

 If I understand things correctly, you say this draft can only be used for 
 A.1 and B.1?

 I think that should be spelled out very explicitly in section 2.

 We had specifically decided not to allow B.2 because we don't want
 this be be used to go from signed to unsigned.

 That is fine.

 You also cannot use
 this for initial enrollment of keys (A.2 - explained in Section 2.2.2
  the security considerations section), you can only use it for
 introducing new keys when you have one working key and removing all
 except the last key. Added text to clarify what use cases we do and do
 not support.

 Thanks!

 We also had, in the intro: This proposal does not include all
 operations needed for the maintenance of DNSSEC key material,
 specifically the introduction or complete removal of all keys.

 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

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

[Warren Kumari]

On Fri, Apr 11, 2014 at 7:10 AM, Patrik Fältström p...@frobbit.se wrote:

 On 11 apr 2014, at 12:03, Antoin Verschuren antoin.verschu...@sidn.nl wrote:

 I think since this is a protocol definition, CDS and CDNSKEY MUST
 match. What a parent should do when the protocol is violated is I
 guess an implementation issue, BCP, or perhaps even local policy. A
 parent may only look at CDNSKEY or CDS or both. Saying they MUST match
 when they are both in the zone does not state anything on what the
 parent should do when they don't, same as when the Rdata is rubish.

 I support this. This makes possible for parents to decide themselves whether:

 1. They only fetch CDNSKEY and will not fetch CDS
 2. They only fetch CDS and will not fetch CDNSKEY
 3. They fetch CDNSKEY first, and then CDS if CDNSKEY does not exist
 4. They fetch CDS and first, and then CDNSKEY if CDS does not exist
 5. They fetch both CDS and CDNSKEY and will only pick data if the two are the 
 same
 6, ...

 Etc.

 If that is not the case, i.e. that the wg want a specific algorithm, then 
 that should be explicit.

 Unless we have an algorithm, then I support the fact that according to the 
 protocol, they MUST result in the same result, as the parent can choose what 
 algorithm they use.

Yup. The document currently (-04) says that if the child publishes
both, they MUST match. However, it also says that the parent MUST NOT
perform a consistency check -- it chooses either DS or DNSKEY based
upon local policy and then consumes the corresponding record type.

Relevant text:
Some parents prefer to accept DNSSEC key information in DS format,
some parents prefer to accept it in DNSKEY format, and calculate the
DS record on the child's behalf. Each method has pros and cons, both
technical and policy. This solution is DS vs DNSKEY agnostic, and
allows operation with either.

The child SHOULD publish both CDS and CDNSKEY records. 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 MUST NOT query for both and
perform consistency checks between the CDS and CDNSKEY records.

The parent MUST choose to accept either CDS or CDNSKEY records (based
upon local policy), and MUST NOT expect there to be both. A parent
MUST NOT perform a consistency check between CDS and CDNSKEY (other
than for informational / debugging use).

Is this A: sane and B: reasonable?

W



Patrik




 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

[ Top post ]
We have received a number of comments, and are integrating them.
So far we have mostly just covered Patrik's - I'm posting a newer
version with some of these integrated, so it's easier for folk to see
what the doc looks like with the changes. We plan to post a more
updated version with Paul / Ed's comments later...



On Thu, Apr 3, 2014 at 6:09 PM, Patrik Fältström p...@frobbit.se wrote:
 First of all, let me thank the people that have been working so hard on this. 
 I have followed the process, but now again re-read the whole thing, and 
 because of that have some comments. Ignore or think about... :-)

This document describes a method for automating maintanance of the
delegation trust information, and proposes a polled / periodic
trigger for simplicity.  Some users may prefer a different trigger,
such as a button on a webpage, a REST interface, DNS NOTIFY, etc.
These alternate / additional triggers are not discussed in this
document.

 This is good, but as I would like to have added in the Security 
 Considerations Section (see below) having multiple paths between child dns 
 operator and parental agent increases the risk there are inconsistencies (if 
 intermediary systems are caching information flowing along the paths).

 Because of this, I do not mind having some extra words here, like:

 This proposal do not include all operations needed for maintenance of DNSSEC 
 key material, specifically introduction and complete removal of all keys. 
 Because of this alternate communications mechanisms must always exist, which 
 might introduce extra complexity.

DONE.


 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

 2.2.2.  DNSSEC key change process

After a Child DNS operator first signs the zone, there is a need to
interact with the Parent, for example via the delegation account
interface, to upload / paste-in the zone's DS information.  The
action of logging in through the delegation account user interface
authenticates that the user is authorized to change delegation
information for the child published in the parent zone.  In the case
where the Child DNS Operator does not have access to the
registration account, the Child needs to perform the action.

At a later date, the Child DNS Operator may want to publish a new DS
record in the parent, either because they are rolling keys, or
because they want to publish a stand-by key.  This involves
performing the same process as before.  Furthermore when this is a
manual process with cut and paste, operational mistakes will happen
-- or worse, the update action is not performed at all.

 Should it not be mentioned here that child might want to remove all keys as 
 well? I mean, if this is supposed to be a complete list of potential 
 operations the child is interested in?

 I see in fact (with some special cases):

 A. Introduction of new keys

 A.1. Introduction when old keys exists and can be used

 A.2. Introduction when no old keys can be used (because they can not be 
 trusted or because no such exists)

 B. Removal of keys

 B.1. Removal of old keys when at least one key still remains in the RRSet of 
 zone apex

 B.2. Removal of last key from the RRSet of the zone apex

 If I understand things correctly, you say this draft can only be used for A.1 
 and B.1?

 I think that should be spelled out very explicitly in section 2.

We had specifically decided not to allow B.2 because we don't want
this be be used to go from signed to unsigned. You also cannot use
this for initial enrollment of keys (A.2 - explained in Section 2.2.2
 the security considerations section), you can only use it for
introducing new keys when you have one working key and removing all
except the last key. Added text to clarify what use cases we do and do
not support.

We also had, in the intro: This proposal does not include all
operations needed for the maintenance of DNSSEC key material,
specifically the introduction or complete removal of all keys.

 4.  Automating DS maintainance with CDS/CDNSKEY records

CDS/CDNSKEY records are intended to be consumed by delegation trust

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

[Patrik Fältström]

On 10 apr 2014, at 18:34, Warren Kumari war...@kumari.net wrote:

 Because of this, I do not mind having some extra words here, like:
 
 This proposal do not include all operations needed for maintenance of 
 DNSSEC key material, specifically introduction and complete removal of all 
 keys. Because of this alternate communications mechanisms must always exist, 
 which might introduce extra complexity.
 
 DONE.

Thanks!

 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.

 2.2.2.  DNSSEC key change process
 
   After a Child DNS operator first signs the zone, there is a need to
   interact with the Parent, for example via the delegation account
   interface, to upload / paste-in the zone's DS information.  The
   action of logging in through the delegation account user interface
   authenticates that the user is authorized to change delegation
   information for the child published in the parent zone.  In the case
   where the Child DNS Operator does not have access to the
   registration account, the Child needs to perform the action.
 
   At a later date, the Child DNS Operator may want to publish a new DS
   record in the parent, either because they are rolling keys, or
   because they want to publish a stand-by key.  This involves
   performing the same process as before.  Furthermore when this is a
   manual process with cut and paste, operational mistakes will happen
   -- or worse, the update action is not performed at all.
 
 Should it not be mentioned here that child might want to remove all keys as 
 well? I mean, if this is supposed to be a complete list of potential 
 operations the child is interested in?
 
 I see in fact (with some special cases):
 
 A. Introduction of new keys
 
 A.1. Introduction when old keys exists and can be used
 
 A.2. Introduction when no old keys can be used (because they can not be 
 trusted or because no such exists)
 
 B. Removal of keys
 
 B.1. Removal of old keys when at least one key still remains in the RRSet of 
 zone apex
 
 B.2. Removal of last key from the RRSet of the zone apex
 
 If I understand things correctly, you say this draft can only be used for 
 A.1 and B.1?
 
 I think that should be spelled out very explicitly in section 2.
 
 We had specifically decided not to allow B.2 because we don't want
 this be be used to go from signed to unsigned.

That is fine.

 You also cannot use
 this for initial enrollment of keys (A.2 - explained in Section 2.2.2
  the security considerations section), you can only use it for
 introducing new keys when you have one working key and removing all
 except the last key. Added text to clarify what use cases we do and do
 not support.

Thanks!

 We also had, in the intro: This proposal does not include all
 operations needed for the maintenance of DNSSEC key material,
 specifically the introduction or complete removal of all keys.

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.

 4.  Automating DS maintainance with CDS/CDNSKEY records
 
   CDS/CDNSKEY records are intended to be consumed by delegation trust
   maintainers.  The use of CDS/CDNSKEY is optional.
 
   Some parents prefer to accept DNSSEC key information in DS format,
   some parents prefer to accept it in DNSKEY format, and calculate the
   DS record on the child's behalf.  Each method has pros and cons, both
   technical and policy.  This solution is DS vs DNSKEY agnostic, and
   allows operation with either.
 
   If the child knows what the parent prefers, they can publish the
   parent's preferred record type.  If the child does not know (or
   simply chooses to), they can publish both CDS and CDNSKEY.  If the
   child publishes both, the two RRsets they SHOULD match in content.
 
 Why not a MUST?
 
 DONE.
 Ok, this is somewhat of a philosophical discussion -- I'm always
 uncomfortable putting a MUST on anything where a user enters the
 information.

Aha.

 Users (in my experience) seem to 

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

[Patrik Fältström]

On 3 Apr 2014, at 12:09, Patrik Fältström p...@frobbit.se wrote:

 What does would be a good idea mean in RFC 1918 speak? :-)

Hmm...not enough coffee...RFC 2119 of course.

   Patrik



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Edward Lewis]

Last summer I believed that this draft was vitally important, but, and as the 
editor’s know, I am less optimistic.

Below is a minor nit to start and then trying to re-write (for my benefit) the 
protocol this is describing.  I did the latter to try to clean up a lot of 
loose language and in the process found three red flags.

I’m not saying don’t publish this - it isn’t standards track.  (Is there still 
an experimental track?)  But in the name of protocol specifications, there are 
a number of places this can be cleaned up.   Even if it won’t scale (because 
not everyone cares about zones with over a million cut points), I can’t see who 
interoperable code can be written with so many loose ends.

On Apr 2, 2014, at 15:07, Tim Wicinski tjw.i...@gmail.com wrote:

 Greetings,
 
 This is the starting of the WGLC on Automating DNSSEC delegation trust 
 maintenance.  This was briefly covered in London and these are ready for 
 WGLC.   The current versions of this documents can be found here:
 
 
 https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
 
 http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt

3.  CDS / CDNSKEY (Child DS/ Child DNSKEY) record definitions

   This document specifies two new DNS RRtypes (CDS and CDNSKEY) that
   indicates what the Child wants the parent's DS RRset to contain.  ...
Poorly written and leads to the wrong interpretation. I would read the above to 
say that SLD.example. will use these to types to indicate what it wants 
example./IN/DS to be.  A suggested fix:
This document specifies two new resource records, CDS and CDNSKEY.  These 
records are used to convey, from one zone to it’s parent, the desired contents 
of the zone’s DS resource record set residing in the parent zone.
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.

   Following acceptance rules are placed on the CDS / CDNSKEY records as
   follows:

   o  Location: the CDS / CDNSKEY record MUST be at the child zone
  apex.

   o  Signer: MUST be signed with a key that is represented in both the
  current DNSKEY and DS RRset's.

   o  Continuity: SHOULD NOT break the current delegation if applied to
  DS RRset

   If any these conditions fail the CDS / CDNSKEY record MUST be
   ignored.

Particularly the rule for the signer.  (To disclose some background - I’ve 
voiced displeasure about this before.)  Before you laugh at how long this is, 
how late this is in the process, this is how I would break down the protocol 
being specified.  I think it’s close to what is in the draft, but, written this 
way, makes be dubious that this is a stable protocol.

(E.g., what action do DNS servers and clients take when a record MUST be 
ignored?)

In the spirit that the CDS/CDNSKEY records are said in section 3 to be “regular 
RR types” and that in RFC 4035 there’s no mention of checking for the SEP flag 
in validation (section 5.3.1), the MUST represents a fracture to me.  I propose 
that the rule be changed to this:

The CDS/DDNSKEY set MUST be signed and validated as any other RRSet in the zone 
(except for the zone’s own DNSKEY set) for the purposes of DNSSEC processing.  
In addition, to indicate that the record set is authorized to convey a new 
secure entry point, the signer MUST also include a signature generated from a 
key that is in the zone’s DNSKEY and DS sets.  This signature MUST be validated 
before the change to the current DS set is authorized.

The wording in there is a bit funky because the passage above is not using what 
I’d call “standard” terminology.  The “Signer” I assume to be the child zone 
signature generation process.

——Okay, at this point, I couldn’t resist mashing this into a specification of a 
protocol:

If were to rewrite 4.1 more radically:

4.1 Processing Rules  (Note - some of these appear in later sections of the 
document, not always the way I say them here.)

The processing rules apply to both ordinary DNS protocol operations 
(query/response, zone transfer) and to the application-specific nature of these 
records.  I.e., these records are used as input to the process of generating a 
zone’s contents which is sometimes called provisioning.  It is for this latter 
purpose that special rules exist.

4.1.1. Publication Rules

An owner of a CDS RR set MAY also own a CDNSKEY RR set.  In general practice, 
only one or the other SHOULD be present, but there may be cases when both are 
needed.

The owner of a CDS/CDNSKEY RR set SHOULD be in the process of requesting a 
change to the owner’s DS RR set.  An owner MAY retain a CDS/CDNSKEY once the 
request has been granted but this will cause unnecessary processing by the 
parent. (RED FLAG #1)
 
A CDS/CDNSKEY set MUST be owned 

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

[Tim Wicinski]

Greetings,

This is the starting of the WGLC on Automating DNSSEC delegation trust 
maintenance.  This was briefly covered in London and these are ready for 
WGLC.   The current versions of this documents can be found here:


https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt


We'll have a 2 week period for comments, closing on April 16th, 2014.

thanks
tim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop