Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt

From: "Marc Lampo" <[email-masked]>
Date: Mon, 2 Apr 2012 16:35:52 +0200 (CEST)

Hello to the list,

Nice piece of work !

Some remarks - nothing spectacular :
1) Last sentence in the first paragraph - Introduction
   (about :
    "no direct relation between ... and validating caching name servers.")

   Isn't this sentence superfluous ?  I fail to see where a possible
   relation would indeed change something to these guidelines.

   But by including the sentence about no relationship,
    one starts to wonder if something escapes me ...

2) Double Signature ZSK rollover in 4.1.1.3
   The last sentence states there are three steps.
   I think this is an error :
    There are three states, yes;
    but there are only two manipulations to perform.
    (to me it seems logical to interpret "step" as :
     "operation to perform")

3) 4.1.3 Difference between ZSK and KSK rollovers
   4.3.3 Security Lameness

   (actually, 4.1.3 introduces another way of KSK rollover.
    In that respect the title of the section is confusing !)

   In 4.1.3 the text suggest to publish a DS record in the parent
    for which there is no DNSKEY record in the child zone.
   In 4.3.3 the text suggest the parent could verify that
    the DNSKEY is actually published by the child.

   --> 4.3.3 could explicitly state that, if a parent performs
        this kind of checking, then the "double DS method"
        of 4.1.3 is not possible.

  Furthermore :
   as registry (for .eu) we think that it is important to assist
   our registrars in setting DNSSEC up correctly.
   Consequently, we do verification when a registrar sends us
   DNSSEC information.  So we cannot distinguish between
   a DNS Operator that performs double DS KSK rollover and
   an operator making a mistake ...

4) 4.3.4 DS Signature Validity Period
   The last paragraph holds a sentence that states :
   "Shortening the TTL reduces the damage of a successful replay attack."

   I don't think this is correct (or relevant).
   For me, the chances for a replay attack increase with the signature
   validity period, not with the value of the TTL.
   The value of the paragraph lays, for me, in the propagation of updated
   DS RRsets (cfr the presentation on low TTL's, last week).

5) 4.4.2.1 Maximum value (for Signature Validation Period)

   I think this paragraph should make a reference to Key Rollover !
   Motivation : no matter how long a signature is valid,
    in order for it to be used, the corresponding Key must be available.
    (so : if the reason for long RRSIG validity is not to recalculate them,
          then ...)

   I do admit that none of the Key Rollover scenario's take into
   account the signature validity time (but the TTL).
   And indeed, nothing prevents to generate a signature, valid for 1 year,
   with TTL of 1 day, and perform key rollover every three months :
   the still valid signature simply times out of the cache,
   to be replaced by a new one, valid for a new year.

Kind regards,

Marc Lampo
EURid (for .eu)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 30 March 2012 11:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Operations 
Working Group of the IETF.

	Title           : DNSSEC Operational Practices, Version 2
	Author(s)       : Olaf M. Kolkman
                          W. (Matthijs) Mekking
	Filename        : draft-ietf-dnsop-rfc4641bis-10.txt
	Pages           : 78
	Date            : 2012-03-30

   This document describes a set of practices for operating the DNS with
   security extensions (DNSSEC).  The target audience is zone
   administrators deploying DNSSEC.

   The document discusses operational aspects of using keys and
   signatures in the DNS.  It discusses issues of key generation, key
   storage, signature generation, key rollover, and related policies.

   This document obsoletes RFC 4641 as it covers more operational ground
   and gives more up-to-date requirements with respect to key sizes and
   the DNSSEC operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 03 Apr 2012 10:36:15 +0200

Hi,

On 04/02/2012 04:35 PM, Marc Lampo wrote:
> Hello to the list,
> 
> Nice piece of work !
> 
> Some remarks - nothing spectacular : 1) Last sentence in the first
> paragraph - Introduction (about : "no direct relation between ...
> and validating caching name servers.")
> 
> But by including the sentence about no relationship, one starts to
> wonder if something escapes me ...

The document just tries to make it very clear that it is targeted to
the authoritative side of the DNS equation.

> 
> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence
> states there are three steps. I think this is an error : There are
> three states, yes; but there are only two manipulations to
> perform. (to me it seems logical to interpret "step" as : 
> "operation to perform")

Sure. More important is the fact that it is one step/stage shorter
than Pre-publish ZSK rollover.

> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security
> Lameness
> 
> (actually, 4.1.3 introduces another way of KSK rollover. In that
> respect the title of the section is confusing !)
> 
> In 4.1.3 the text suggest to publish a DS record in the parent for
> which there is no DNSKEY record in the child zone.

It suggests to publish a DS record for which there is no
*corresponding* DNSKEY record in the child zone, next to an existing
chain of trust between parent and child. That is different from "no
DNSKEY record in the child zone".

> In 4.3.3 the text suggest the parent could verify that the DNSKEY
> is actually published by the child.
> 
> --> 4.3.3 could explicitly state that, if a parent performs this
> kind of checking, then the "double DS method" of 4.1.3 is not
> possible.

There is already a forward reference in section 4.1.3 to 4.3.3.

> Furthermore : as registry (for .eu) we think that it is important
> to assist our registrars in setting DNSSEC up correctly. 
> Consequently, we do verification when a registrar sends us DNSSEC
> information.  So we cannot distinguish between a DNS Operator that
> performs double DS KSK rollover and an operator making a mistake
> ...

I think you might have a false negative there: If a DNS operator
requests for a second DS to be published, it does not break the chain
of trust. Why classify it as a mistake? Double-DS rollover is
perfectly acceptable within the boundaries of DNSSEC.

> 4) 4.3.4 DS Signature Validity Period The last paragraph holds a
> sentence that states : "Shortening the TTL reduces the damage of a
> successful replay attack."
> 
> I don't think this is correct (or relevant). For me, the chances
> for a replay attack increase with the signature validity period,
> not with the value of the TTL. The value of the paragraph lays, for
> me, in the propagation of updated DS RRsets (cfr the presentation
> on low TTL's, last week).

You are right that the chances for a replay attack increase with the
validity period, but the damage depends on how long that data will be
in the cache. That depends on TTL.

> Motivation : no matter how long a signature is valid, in order for
> it to be used, the corresponding Key must be available. (so : if
> the reason for long RRSIG validity is not to recalculate them, then
> ...)
> 
> account the signature validity time (but the TTL). And indeed,
> nothing prevents to generate a signature, valid for 1 year, with
> TTL of 1 day, and perform key rollover every three months : the
> still valid signature simply times out of the cache, to be replaced
> by a new one, valid for a new year.

Hence, I don't think this paragraph should make a reference to key
rollover.

Best regards,
  Matthijs

> 
> Kind regards,
> 
> Marc Lampo EURid (for .eu)
> 
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: 30 March 2012 11:36 AM To:
> [email-masked] Cc: [email-masked] Subject: [DNSOP] I-D
> Action: draft-ietf-dnsop-rfc4641bis-10.txt
> 
> 
>  directories. This draft is a work item of the Domain Name System
> Operations Working Group of the IETF.
> 
> Title           : DNSSEC Operational Practices, Version 2 Author(s)
> : Olaf M. Kolkman W. (Matthijs) Mekking Filename        :
> draft-ietf-dnsop-rfc4641bis-10.txt Pages           : 78 Date
> : 2012-03-30
> 
> This document describes a set of practices for operating the DNS
> with security extensions (DNSSEC).  The target audience is zone 
> This document obsoletes RFC 4641 as it covers more operational
> ground and gives more up-to-date requirements with respect to key
> sizes and the DNSSEC operations.
> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 3 Apr 2012 11:11:51 +0200 (CEST)

Hello again,

About 1)
If the document is for the authoritative side,
why not simply state so.  Instead of this confusing statement
about relationship between authoritative and validating NS's ?

About 2)
So it is "two" steps ?

About 3)
I forgot the word "corresponding", my fault there.
As such the text is not wrong, please don't misunderstand me.
But the parent the only way, for a parent, to known/verify
that DS information is correct, is by querying for the DNSKEY RRset
and check if the corresponding ( ;-) DNSKEY is indeed present.
If it is not, there is no way the parent can distinguish between
a child zone administrator performing a double-DS rollover
or making an error ...

About 4)
I can agree with the present text.

About 5)
Me too, I think published signatures should never be expired.
Consequently, every key rollover will make signatures disappear
that are, as such, not expired yet.
>From that point of view it makes little difference if
signature validity period is a couple of weeks or months or years.

But if the zone administrator uses long validity time
with the intention not to recalculate regularly,
this implies that the ZSK cannot rollover either.
(and this is practice - out there, right now !
 There is one TLD that has signatures valid till "the end of the current
year",
 and never did any key rollover since it started with DNSSEC)

To conclude : I can "just" agree with the present text.

Kind regards,

Marc Lampo
EURid (for .eu)

-----Original Message-----
From: Matthijs Mekking [mailto:[email-masked]] 
Sent: 03 April 2012 10:36 AM
To: Marc Lampo
Cc: [email-masked]
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt

Hi,

> wonder if something escapes me ...

The document just tries to make it very clear that it is targeted to the
authoritative side of the DNS equation.

> 
> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states 
> there are three steps. I think this is an error : There are three 
> states, yes; but there are only two manipulations to perform. (to me 
> it seems logical to interpret "step" as :
> "operation to perform")

Sure. More important is the fact that it is one step/stage shorter than
Pre-publish ZSK rollover.

It suggests to publish a DS record for which there is no
*corresponding* DNSKEY record in the child zone, next to an existing chain
of trust between parent and child. That is different from "no DNSKEY
record in the child zone".

> In 4.3.3 the text suggest the parent could verify that the DNSKEY is 
> actually published by the child.
> 

> Furthermore : as registry (for .eu) we think that it is important to 
> assist our registrars in setting DNSSEC up correctly.
> performs double DS KSK rollover and an operator making a mistake ...

I think you might have a false negative there: If a DNS operator requests
for a second DS to be published, it does not break the chain of trust. Why
classify it as a mistake? Double-DS rollover is perfectly acceptable
within the boundaries of DNSSEC.

> I don't think this is correct (or relevant). For me, the chances for a 
> replay attack increase with the signature validity period, not with 
> the value of the TTL. The value of the paragraph lays, for me, in the 
> propagation of updated DS RRsets (cfr the presentation on low TTL's, 
> last week).

You are right that the chances for a replay attack increase with the
validity period, but the damage depends on how long that data will be in
the cache. That depends on TTL.

> Motivation : no matter how long a signature is valid, in order for it 
> to be used, the corresponding Key must be available. (so : if the 
> reason for long RRSIG validity is not to recalculate them, then
> ...)
> 
> I do admit that none of the Key Rollover scenario's take into account 
> the signature validity time (but the TTL). And indeed, nothing 
> prevents to generate a signature, valid for 1 year, with TTL of 1 day, 
> and perform key rollover every three months : the still valid 
> signature simply times out of the cache, to be replaced by a new one, 
> valid for a new year.

Best regards,
  Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 12 Apr 2012 10:52:34 +0200

Hi Marc,

Coming back to your review items, I only think point 1 is not decided
on yet. But I don't think this should stop progress.

You can find my responses in between lines.

Best regards,
  Matthijs

On 04/03/2012 11:11 AM, Marc Lampo wrote:
> Hello again,
> 
> About 1) If the document is for the authoritative side, why not
> simply state so.  Instead of this confusing statement about
> relationship between authoritative and validating NS's ?

I believe it does state so, without confusion: The first sentence says
the document is aimed for people that are active at the authoritative
side. The second sentence says that we consider no relationship with
the people running the recursive side. You think the document can do
without the latter sentence. I think it is a fair assumption.

> About 2) So it is "two" steps ?

I made it three stages. ;)

> About 3) I forgot the word "corresponding", my fault there. As such
> the text is not wrong, please don't misunderstand me. But the
> parent the only way, for a parent, to known/verify that DS
> information is correct, is by querying for the DNSKEY RRset and
> check if the corresponding ( ;-) DNSKEY is indeed present. If it is
> not, there is no way the parent can distinguish between a child
> zone administrator performing a double-DS rollover or making an
> error ...

The text is not wrong, so we do not need action for 4641bis here.

My point of view on this topic:

As long as there is a valid DS with corresponding DNSKEY, adding
another DS is no error. Maybe you are afraid what happens if the child
zone operator removes the old DNSKEY and replaces it with the new
(mismatched) one. Now you have encountered the error. But such things
are not specific to Double-DS rollover, it can happen also without
being in a rollover: I could remove my DNSKEYs from my zone, and it
would go bogus. Same thing.

My point is, as long as the zone is able to be validated, there is no
error made (in terms of DNSSEC).

> About 4) I can agree with the present text.

Ok.

> About 5) Me too, I think published signatures should never be
> expired. Consequently, every key rollover will make signatures
> disappear that are, as such, not expired yet. From that point of
> view it makes little difference if signature validity period is a
> couple of weeks or months or years.
> 
> But if the zone administrator uses long validity time with the
> intention not to recalculate regularly, this implies that the ZSK
> cannot rollover either. (and this is practice - out there, right
> now ! There is one TLD that has signatures valid till "the end of
> the current year", and never did any key rollover since it started
> with DNSSEC)
> 

Ok.

> -----Original Message----- From: Matthijs Mekking
> [mailto:[email-masked]] Sent: 03 April 2012 10:36 AM To:
> Marc Lampo Cc: [email-masked] Subject: Re: [DNSOP] I-D Action:
> draft-ietf-dnsop-rfc4641bis-10.txt
> 
> Hi,
> 
>> Some remarks - nothing spectacular : 1) Last sentence in the
>> first paragraph - Introduction (about : "no direct relation
>> between ... and validating caching name servers.")
> 
>> But by including the sentence about no relationship, one starts
>> to wonder if something escapes me ...
> 
> The document just tries to make it very clear that it is targeted
> to the authoritative side of the DNS equation.
> 
> 
>> states there are three steps. I think this is an error : There
>> are three states, yes; but there are only two manipulations to
> *corresponding* DNSKEY record in the child zone, next to an
> existing chain of trust between parent and child. That is different
> from "no DNSKEY record in the child zone".
> 
>>  information.  So we cannot distinguish between a DNS Operator
>> that performs double DS KSK rollover and an operator making a
>> mistake ...
> 
> requests for a second DS to be published, it does not break the
> chain of trust. Why classify it as a mistake? Double-DS rollover is
>>  sentence that states : "Shortening the TTL reduces the damage of
>> a successful replay attack."
> 
>> not with the value of the TTL. The value of the paragraph lays,
>> for me, in the propagation of updated DS RRsets (cfr the
>> presentation on low TTL's, last week).
> 
> You are right that the chances for a replay attack increase with
> the validity period, but the damage depends on how long that data
> will be in the cache. That depends on TTL.
> 
>>  Motivation : no matter how long a signature is valid, in order
>> for it to be used, the corresponding Key must be available. (so :
>> if the reason for long RRSIG validity is not to recalculate them,
>> then ...)
> 
>> still valid signature simply times out of the cache, to be
>> replaced by a new one, valid for a new year.
> 
> Best regards, Matthijs
>> [mailto:[email-masked]] Sent: 30 March 2012 11:36 AM
>> To: [email-masked] Cc: [email-masked] Subject: [DNSOP]
>> I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
> 
> 
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> Domain Name System Operations Working Group of the IETF.
> 
>> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename
>> : draft-ietf-dnsop-rfc4641bis-10.txt Pages           : 78 Date :
>> 2012-03-30
> 
>> signatures in the DNS.  It discusses issues of key generation,
>> key storage, signature generation, key rollover, and related
>> policies.
> 
>> _______________________________________________ DNSOP mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Marc Lampo" <[email-masked]>
Date: Thu, 12 Apr 2012 12:48:58 +0200 (CEST)

Hello Matthijs,

Regarding 1 - "... no relationship ... validating ... "

Suggestion (a phrase that does not hint at any possible "relationship") :
This document holds no information that applies to the configuration
of validating recursive name servers (validators).

Ok regarding 2 : three stages

OK regarding 3 : consequences for validation by parents

(as a matter of fact,
 we're going to check if we adapt our present validation ourselves)

For 4 and 5 there was already an OK.

Kind regards,

Marc

-----Original Message-----
From: Matthijs Mekking [mailto:[email-masked]] 
Sent: 12 April 2012 10:53 AM
To: Marc Lampo
Cc: [email-masked]
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt

Hi Marc,

Coming back to your review items, I only think point 1 is not decided on
yet. But I don't think this should stop progress.

Best regards,
  Matthijs

On 04/03/2012 11:11 AM, Marc Lampo wrote:
> Hello again,
> 
> About 1) If the document is for the authoritative side, why not simply 
> state so.  Instead of this confusing statement about relationship 
> between authoritative and validating NS's ?

I believe it does state so, without confusion: The first sentence says the
document is aimed for people that are active at the authoritative side.
The second sentence says that we consider no relationship with the people
running the recursive side. You think the document can do without the
latter sentence. I think it is a fair assumption.

> the text is not wrong, please don't misunderstand me. But the parent 
> the only way, for a parent, to known/verify that DS information is 
> correct, is by querying for the DNSKEY RRset and check if the 
> corresponding ( ;-) DNSKEY is indeed present. If it is not, there is 
> no way the parent can distinguish between a child zone administrator 
> performing a double-DS rollover or making an error ...

As long as there is a valid DS with corresponding DNSKEY, adding another
DS is no error. Maybe you are afraid what happens if the child zone
operator removes the old DNSKEY and replaces it with the new
(mismatched) one. Now you have encountered the error. But such things are
not specific to Double-DS rollover, it can happen also without being in a
rollover: I could remove my DNSKEYs from my zone, and it would go bogus.
Same thing.

Ok.

> About 5) Me too, I think published signatures should never be expired. 
> Consequently, every key rollover will make signatures disappear that 
> are, as such, not expired yet. From that point of view it makes little 
> difference if signature validity period is a couple of weeks or months 
> or years.
> 
> cannot rollover either. (and this is practice - out there, right now ! 
> There is one TLD that has signatures valid till "the end of the 
> current year", and never did any key rollover since it started with 
> DNSSEC)
> 

Ok.

>> paragraph - Introduction (about : "no direct relation between ... and 
>> validating caching name servers.")
> 
>> I don't think this is correct (or relevant). For me, the chances for 
>> a replay attack increase with the signature validity period, not with 
>> it to be used, the corresponding Key must be available. (so :
>> prevents to generate a signature, valid for 1 year, with TTL of 1 
>> day, and perform key rollover every three months : the still valid 
>> To: [email-masked] Cc: [email-masked] Subject: [DNSOP] I-D

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 12 Apr 2012 13:03:58 +0200

On 04/12/2012 12:48 PM, Marc Lampo wrote:
> Suggestion (a phrase that does not hint at any possible
> "relationship") : This document holds no information that applies
> to the configuration of validating recursive name servers
> (validators).

Not only that, also the entities on the authoritative side don't have
influence on the entities on the recursive side.

> (as a matter of fact, we're going to check if we adapt our present
> validation ourselves)
> 
> [mailto:[email-masked]] Sent: 12 April 2012 10:53 AM To:
> Coming back to your review items, I only think point 1 is not
> decided on yet. But I don't think this should stop progress.
> 
> I believe it does state so, without confusion: The first sentence
> says the document is aimed for people that are active at the
> authoritative side. The second sentence says that we consider no
> relationship with the people running the recursive side. You think
> the document can do without the latter sentence. I think it is a
> fair assumption.
> 
>> About 3) I forgot the word "corresponding", my fault there. As
>> such the text is not wrong, please don't misunderstand me. But
>> the parent the only way, for a parent, to known/verify that DS
>> check if the corresponding ( ;-) DNSKEY is indeed present. If it
>> is not, there is no way the parent can distinguish between a
>> child zone administrator performing a double-DS rollover or
>> making an error ...
> 
> another DS is no error. Maybe you are afraid what happens if the
> child zone operator removes the old DNSKEY and replaces it with the
> new (mismatched) one. Now you have encountered the error. But such
> things are not specific to Double-DS rollover, it can happen also
> without being in a rollover: I could remove my DNSKEYs from my
> zone, and it would go bogus. Same thing.
> 
> My point is, as long as the zone is able to be validated, there is
> no error made (in terms of DNSSEC).
> 
>> the current year", and never did any key rollover since it
>> started with DNSSEC)
> 
>>> Isn't this sentence superfluous ?  I fail to see where a
>>> possible relation would indeed change something to these
>>> guidelines.
> 
>> Sure. More important is the fact that it is one step/stage
>> shorter than Pre-publish ZSK rollover.
> 
>>> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3
>>> Security Lameness
> 
>>> (actually, 4.1.3 introduces another way of KSK rollover. In
>>> that respect the title of the section is confusing !)
> 
>> existing chain of trust between parent and child. That is
>> different from "no DNSKEY record in the child zone".
> 
>>> In 4.3.3 the text suggest the parent could verify that the
>>> DNSKEY is actually published by the child.
> 
>>> this kind of checking, then the "double DS method" of 4.1.3 is
>>> not possible.
> 
>>> Furthermore : as registry (for .eu) we think that it is
>>> important to assist our registrars in setting DNSSEC up
>>> correctly. Consequently, we do verification when a registrar
>>> sends us DNSSEC information.  So we cannot distinguish between
>>> a DNS Operator that performs double DS KSK rollover and an
>>> operator making a mistake ...
> 
>> chain of trust. Why classify it as a mistake? Double-DS rollover
>> is perfectly acceptable within the boundaries of DNSSEC.
> 
>>> 4) 4.3.4 DS Signature Validity Period The last paragraph holds
>>> a sentence that states : "Shortening the TTL reduces the damage
>>> of a successful replay attack."
> 
>>> I don't think this is correct (or relevant). For me, the
>>> chances for a replay attack increase with the signature
>>> validity period, not with the value of the TTL. The value of
>>> the paragraph lays, for me, in the propagation of updated DS
>>> RRsets (cfr the presentation on low TTL's, last week).
> 
>>> I think this paragraph should make a reference to Key Rollover
>>> ! Motivation : no matter how long a signature is valid, in
>>> order for it to be used, the corresponding Key must be
>>> available. (so : if the reason for long RRSIG validity is not
>>> to recalculate them, then ...)
> 
>>> nothing prevents to generate a signature, valid for 1 year,
>>> with TTL of 1 day, and perform key rollover every three months
>>> : the still valid signature simply times out of the cache, to
>>> be replaced by a new one, valid for a new year.
> 
>> Hence, I don't think this paragraph should make a reference to
>> key rollover.
> 
>> Best regards, Matthijs
> 
> 
>>> Kind regards,
> 
>>> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename :
>>> draft-ietf-dnsop-rfc4641bis-10.txt Pages           : 78 Date : 
>>> 2012-03-30
> 
>>> This document describes a set of practices for operating the
>>> DNS with security extensions (DNSSEC).  The target audience is
>>> zone administrators deploying DNSSEC.
> 
>>> ground and gives more up-to-date requirements with respect to
>>> key sizes and the DNSSEC operations.
> 
> 
>>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx
>>>
>>> 
t
>>> list [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Marc Lampo" <[email-masked]>
Date: Thu, 12 Apr 2012 14:09:32 +0200 (CEST)

Hello all,

(This also concerns the other discussion about "Negative Trust Anchors",
 I'll post with that subject as well)

-----Original Message-----
> Not only that, also the entities on the authoritative side
> don't have influence on the entities on the recursive side.

Actually, there is something that influences the recursive side !
(I'm referring to 4.3.3 "Security lameness",
 where is state "removing a DS RR")

Since this document is about "DNSSEC Operational Practices",
perhaps include a suggestion that parents regularly (no frequency defined)
check the coherence of DS information they have
against DNSKEY information they find published.
If the parent detects "security lameness" its possible reaction
could be to remove the DS information.

While my company, as registry for .eu, does not do this (yet ?),
we do validate DNSSEC information when submitted,
prior to publishing it as DS records (only if validation yields success).
So, we already decide not to publish wrong information (at one point in
time).
The suggestion to regularly verify again extends that behaviour from
  "not publishing if wrong" (at submission time)
to
  "stop publishing if wrong" (as part of normal operation)
(the contract with registrars states that information provided by
 registrars must be correct.  If not, the contract allows for some
 reactions (like blocking a domain in case of fake identities,
 but - by extension - to correctness of DNSSEC information)

The advantage over negative trust anchor would be that this is more
centrally
managed : the action by the parent (remove DS) is visible (TTL permitted)
 to any validating name server.
 (the negative trust anchor needs to be configured by every validating NS,
   whose administrators bother to do so.
   And good point for Comcast who is obviously committed here !)

I acknowledge that negative trust anchor applies to however the
chain-of-trust
starts (from the root-zone, or from some DLV).  But since the root is
DNSSEC'd
since close to 2 years, I expect the DLV approach is less important
anyway.

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

-----Original Message-----
From: Matthijs Mekking [mailto:[email-masked]] 
Sent: 12 April 2012 01:04 PM
To: Marc Lampo
Cc: [email-masked]
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt

On 04/12/2012 12:48 PM, Marc Lampo wrote:
> "relationship") : This document holds no information that applies to 
> the configuration of validating recursive name servers (validators).

>> disappear that are, as such, not expired yet. From that point of view 
>> it makes little difference if signature validity period is a couple 
>> of weeks or months or years.
> 
>> cannot rollover either. (and this is practice - out there, right now 
>> ! There is one TLD that has signatures valid till "the end of the 
>>> this kind of checking, then the "double DS method" of 4.1.3 is not 
>>> possible.
> 
>>> assist our registrars in setting DNSSEC up correctly. Consequently, 
>>> we do verification when a registrar sends us DNSSEC information.  So 
>>> we cannot distinguish between a DNS Operator that performs double DS 
>>> KSK rollover and an operator making a mistake ...
> 
>>> a replay attack increase with the signature validity period, not 
>>> with the value of the TTL. The value of the paragraph lays, for me, 
>>> in the propagation of updated DS RRsets (cfr the presentation on low 
>>> TTL's, last week).
> 
>>> it to be used, the corresponding Key must be available. (so : if the 
>>> reason for long RRSIG validity is not to recalculate them, then ...)
> 
>>> nothing prevents to generate a signature, valid for 1 year, with TTL 
>>> of 1 day, and perform key rollover every three months
>>> : the still valid signature simply times out of the cache, to be 
t

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 12 Apr 2012 14:32:16 +0200

On 04/12/2012 02:09 PM, Marc Lampo wrote:
> Hello all,
> 
> (This also concerns the other discussion about "Negative Trust
> Anchors", I'll post with that subject as well)
> 
> [mailto:[email-masked]] ...
>> Not only that, also the entities on the authoritative side don't
>> have influence on the entities on the recursive side.
> 
> (I'm referring to 4.3.3 "Security lameness", where is state
> "removing a DS RR")

Sorry that I didn't make myself clear, perhaps influence was a bad
word here. Of course the changes you make in your zone influences the
recursive side. What I (and the document) try to make clear is that
entities on the authoritative side do not have influence on *the
operations* at the recursive side.

Are there more people who think the text in the introduction is
confusing? If so, please speak up and preferably suggest other wordings.

Furthermore, we are shifting away from your review item (1), which was
about the text in the introduction. You are now talking about security
lameness. There are already considerations about that topic in
4641bis. Your suggestion is already there, see Section 4.3.3!

Best regards,
  Matthijs

> perhaps include a suggestion that parents regularly (no frequency
> defined) check the coherence of DS information they have against
> DNSKEY information they find published. If the parent detects
> "security lameness" its possible reaction could be to remove the DS
> information.
> 
> 
> While my company, as registry for .eu, does not do this (yet ?), we
> do validate DNSSEC information when submitted, prior to publishing
> it as DS records (only if validation yields success). So, we
> already decide not to publish wrong information (at one point in 
> time). The suggestion to regularly verify again extends that
> behaviour from "not publishing if wrong" (at submission time) to 
> "stop publishing if wrong" (as part of normal operation) (the
> contract with registrars states that information provided by 
> reactions (like blocking a domain in case of fake identities, but -
> by extension - to correctness of DNSSEC information)
> 
> The advantage over negative trust anchor would be that this is
> more centrally managed : the action by the parent (remove DS) is
> visible (TTL permitted) to any validating name server. (the
> negative trust anchor needs to be configured by every validating
> NS, whose administrators bother to do so. And good point for
> Comcast who is obviously committed here !)
> 
> chain-of-trust starts (from the root-zone, or from some DLV).  But
> since the root is DNSSEC'd since close to 2 years, I expect the DLV
> approach is less important anyway.
> 
> 
> Kind regards,
> 
> Marc Lampo Security Officer EURid (for .eu)
> 
> 
> [mailto:[email-masked]] Sent: 12 April 2012 01:04 PM To:
> Not only that, also the entities on the authoritative side don't
> have influence on the entities on the recursive side.
> 
> 
>> (as a matter of fact, we're going to check if we adapt our
>> present validation ourselves)
> 
>> relationship with the people running the recursive side. You
>> think the document can do without the latter sentence. I think it
>> is a fair assumption.
> 
>>> check if the corresponding ( ;-) DNSKEY is indeed present. If
>>> it is not, there is no way the parent can distinguish between a
>> child zone operator removes the old DNSKEY and replaces it with
>> the new (mismatched) one. Now you have encountered the error. But
>> such things are not specific to Double-DS rollover, it can happen
>> also without being in a rollover: I could remove my DNSKEYs from
>> my zone, and it would go bogus. Same thing.
> 
>> My point is, as long as the zone is able to be validated, there
>> is no error made (in terms of DNSSEC).
> 
>>>  disappear that are, as such, not expired yet. From that point
>>> of view it makes little difference if signature validity period
>>> is a couple of weeks or months or years.
> 
>>>  intention not to recalculate regularly, this implies that the
>>> ZSK cannot rollover either. (and this is practice - out there,
>>> right now ! There is one TLD that has signatures valid till
>>> "the end of the current year", and never did any key rollover
>>> since it started with DNSSEC)
> 
>>> [mailto:[email-masked]] Sent: 03 April 2012 10:36 AM
>>> To: Marc Lampo Cc: [email-masked] Subject: Re: [DNSOP] I-D
>>>> But by including the sentence about no relationship, one
>>>> starts to wonder if something escapes me ...
> 
>>> The document just tries to make it very clear that it is
>>> targeted to the authoritative side of the DNS equation.
> 
> 
>>>> states there are three steps. I think this is an error :
>>>> There are three states, yes; but there are only two
>>>> manipulations to perform. (to me it seems logical to
>>>> interpret "step" as : "operation to perform")
> 
>>>> In 4.1.3 the text suggest to publish a DS record in the
>>>> parent for which there is no DNSKEY record in the child
>>>> zone.
> 
>>>> this kind of checking, then the "double DS method" of 4.1.3
>>>> is not possible.
> 
>>>> sends us DNSSEC information.  So we cannot distinguish
>>>> between a DNS Operator that performs double DS KSK rollover
>>>> and an operator making a mistake ...
> 
>>> I think you might have a false negative there: If a DNS
>>> operator requests for a second DS to be published, it does not
>>> break the chain of trust. Why classify it as a mistake?
>>> Double-DS rollover is perfectly acceptable within the
>>> boundaries of DNSSEC.
> 
>>>> 4) 4.3.4 DS Signature Validity Period The last paragraph
>>>> holds a sentence that states : "Shortening the TTL reduces
>>>> the damage of a successful replay attack."
> 
>>> You are right that the chances for a replay attack increase
>>> with the validity period, but the damage depends on how long
>>> that data will be in the cache. That depends on TTL.
> 
>>>> I think this paragraph should make a reference to Key
>>>> Rollover ! Motivation : no matter how long a signature is
>>>> valid, in order for it to be used, the corresponding Key must
>>>> be available. (so : if the reason for long RRSIG validity is
>>>> not to recalculate them, then ...)
> 
>>>>  account the signature validity time (but the TTL). And
>>>> indeed, nothing prevents to generate a signature, valid for 1
>>>> year, with TTL of 1 day, and perform key rollover every three
>>>> months : the still valid signature simply times out of the
>>>> cache, to be replaced by a new one, valid for a new year.
> 
>>>> [mailto:[email-masked]] Sent: 30 March 2012 11:36
>>>> AM To: [email-masked] Cc: [email-masked] Subject:
>>>> [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
> 
> 
>>>> DNS with security extensions (DNSSEC).  The target audience
>>>> is zone administrators deploying DNSSEC.
> 
>>>>  signatures in the DNS.  It discusses issues of key
>>>> generation, key storage, signature generation, key rollover,
>>>> and related policies.
> 
>>>> This document obsoletes RFC 4641 as it covers more
>>>> operational ground and gives more up-to-date requirements
>>>> with respect to key sizes and the DNSSEC operations.
> 
> 
>>>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.t
>>>>
>>>> 
x
>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx
>>>>
>>>> 
t