Subject: Re: [DNSOP] Comments on RFC4641bis

From: Matthijs Mekking <[email-masked]>
Date: Fri, 18 Feb 2011 12:06:50 +0100

Hi Rickard,

A long email deserves a long response:)

On 11/08/2010 05:51 PM, Rickard Bellgrim wrote:
> Hi Olaf
> 
> Sorry for this long email, but I got some comments on your draft:
> “DNSSEC Operational practices”. It is a good draft this is needed,
> just want to clarify some stuff.
> 
> 1.2 Time Definitions: “Signature publication period” You mention that
> the replacement takes place in the master zone file. You are probably
> not manipulating the master zone file, but rather the data in the
> “signer”. Some solutions do write to a zone file, but is that always
> the case? You also mention that caches need to expire, etc. But it is
> not clear if this time is part of the definition of signature
> publication period or not.

Would it be good enough to abstract from the master zone file, by just
referring to the zone? Proposed text:

  "Signature publication period" The period that a signature is
  published. It starts at the time the signature is introduced in the
  zone for the first time and ends at the time when the signature is
  removed or replaced with a new signature.

> 1.2 Time Definitions: “Key effectivity period” I would define the key
> effectivity period as the time between creating the first signature
> and the last signature with this key. Remember that the inception
> time can be set to a time earlier than now because of the inception
> offset. And that key will become not active during a rollover, but
> the signatures may be reused for some extra days to get a smooth
> rollover of the signatures. So that you do not drop them at the same
> time.

While technically it is true that a key becomes operative once it has
created the first signature, you could also say that for validators it
looks like that the key is in effect since the first signatures are
incepted. The signer pretends as if the key was in effect earlier than
the first signature was actually created.

Not sure if this is important enough to argue about: We talk about key
effectivity periods of months, years and even decades.

> 3.1 Operational Motivations (5th paragraph) Is it true that you get
> “operational flexibility and higher computational performance” by
> using a file based ZSK and smartcard KSK (offline in a safe) than a
> single key stored on an HSM? The HSM can give you the option to have
> the keys online, thus no need to take out the smartcard from the
> safe. And the HSM can be designed to give you speed. I know that my
> HSM is faster than OpenSSL on my machine.

It may be unwise to talk about higher computational performance in this
section. The section motivates scenarios where operators may benefit
from a ZSK/KSK split. The 5th paragraph is worried about key compromise,
and how a split provides you more protection without losing too much of
your operational flexibility. Speed is not a motivation here.

I do agree that 'on-line HSMs' marginalizes the argument in favor of the
split significantly.

> 3.2 Practical Consequences (2nd paragraph) The statement is that you
> can have signature validity periods on the order of days for ZSK
> signatures, because there is no interaction with the parent during a
> key rollover. Well this is not true. There is nothing that prevents
> you from having short validity periods for KSK signatures. ZSK and
> KSK is thus equal in that aspect.

I agree. Paul Wouters responded:

"It depends on how long the parent's DS/NS records are valid for (TTL)
and how fast they can update the DS record. It's not fully in your
control, so there is some possible delay (and you NEED a monitor to
avoid a bad rollover)",

but I think that is more related to KSK rollover, not the KSK signature
validity period.

> 3.2 Practical Consequences (3rd paragraph) During a KSK rollover,
> there will be “interactions with parties other than the zone
> administrator”. This sounds like there is an interaction with the
> zone administrator during a ZSK rollover. It is true if you have an
> offline KSK. But ZSK rollover can be automated if you have the KSK
> online in e.g. an HSM. I would suggest removing the last part of the
> statement.

I agree.

> 3.3 Key Effectivity Period (2nd paragraph) You say that you should
> choose 13 months as the KSK key effectivity period with the intent to
> replace it after 12 months. Why this extra month? The KSK key
> effectivity period is mostly just a policy. You do not know if you
> are able to complete all of the actions that are needed to do the
> rollover on that exact date. After the rollover, you can say that the
> effectivity period was e.g. 12.5 months because the interaction with
> your parent took some time. So before the rollover, the key
> effectivity period is a policy and after the rollover it is a fact.
> Nothing breaks if you take longer time. (The choice of 12 months is
> another discussion...)

I agree. The key effectivity period should not be considered a constant
value. Do you want to start the discussion of 12 months now? ;)

> 3.3 Key Effectivity Period (4th paragraph) Ok, in a lab it might be
> possible to do rollovers every few minutes. But in the real world,
> your DNSKEY RRset would grow really big because of pre- and
> post-publishing of the key (depending on your rollover mechanism).
> And this document is almost like a BCP, should we tell people that
> this is possible?

Although perhaps considered a BCP by some, it is informational. But I
agree that this short paragraph doesn't add much.

> 3.4.1 Key Algorithm (1st paragraph) Don’t forget to mention GOST and
> that DSA (in DNSSEC) is limited to maximum 1024 bit keys.

Ok.

> 3.4.1 Key Algorithm (2nd paragraph) “RSA/MD5 should not be” =>
> “RSA/MD5 must not be”

It is NOT RECOMMENDED in 4034, so I think the should is sufficient here.

> 3.4.2 Key Sizes This section talks about key sizes, but that depends
> on what algorithm you are talking about. Please mention RSA
> somewhere.

Yes.

> 3.4.2 Key Sizes (1st paragraph) “can safely use 1024-bit keys for at
> least the next ten years”. NIST SP 800-131 says that 1024 – 2048 bit
> is acceptable to use in 2010. It is deprecated between 2011 and 2013.
> From 2011 you should use keys larger than 2048 bits. 
> http://csrc.nist.gov/groups/ST/toolkit/documents/draftSP800-131_June_11_2010.pdf

The recommendation is prepared for use by federal agencies. Is DNSSEC
required to follow these guidelines?

>  3.4.2 Key Sizes (1st paragraph) Why mention the equivalent strength
> of a symmetric key if there is no other algorithm to compare with?

It is compared with the typically next larger key size (2048 bits).
Should that comparison be removed as well?

> 3.4.2 Key Sizes (2nd paragraph) “the next larger key size used is
> 2048 bits”. Is this a dramatic increase from 1024 bit, as the next
> larger key? There are more steps between 1024 and 2048 bits.

It says typically. I am inclined to say that we do not have to go into
all possible key sizes.

> 3.4.2 Key Sizes (2nd paragraph) Double the key size will make
> verification four times slower and signing eight times slower (not
> four times). “public key operations take O(k2) steps, private key
> operations take O(k3) steps, and key generation takes O(k4) steps” -
> http://www.rsa.com/rsalabs/node.asp?id=2215

But such notation might be to vaguely for operators.

> 3.4.2 Key Sizes (5th paragraph) DSA in general can have larger keys
> than 1024, but it is limited to 1024 bits in DNSSEC.

Ok.

> 3.4.3 Private Key Storage (2nd paragraph) Not only dynamic updates
> can require that you have “access” to one private key. It is more
> about regular / automatic updates. E.g. that your system push out a
> new zone file every second hour. No system administrator / security
> officer is willing to go to the server room regularly every day.

Added ', or any other mechanism that runs at a regular interval'.

> 3.4.3 Private Key Storage (last paragraph) See arguments above. How
> does this paragraph then fit in?

I don't see a reason for having the private key on-line with your
regular update mechanism. Do you?

> 3.4.4 Key Generation HSM:s also provide a good facility for key
> generation. With good random numbers.

Added the note.

> 4.1 Key Rollovers I would STRONGLY suggest that you minimize this
> section. Just give an overview of how the different rollover methods
> function and compare them with each other. Refer to the key timing
> draft, so that we do not get the timings in two documents.

If I am correct, you are referring to the tables. I believe there is
still strong consensus to keep the tables in here. The tables do not
really go into timing parameters imho, they merely talk about TTL intervals.

> 4.2.1 KSK Compromise (2nd paragraph) A compromised KSK used by an
> attacker can also sign data in the zone other than the key set. An
> attacker does not need to follow the definitions of KSK vs ZSK.

I am guessing that you aim for a small change here: to note that all
RRsets in the zone can be signed with the compromised KSK. I am tempted
not to add this because with a KSK compromise, the key set is
compromised anyway. Signing other RRsets is possible, but seems
arbitrary (like Jelte pointed out as well).

> 4.2.1.1 Keeping the Chain of Trust Intact (1st paragraph) Why do we
> want to make the key set expire in the caches by lowering the
> signature lifetime? Caching is based on the minimum of TTL and
> remaining signature lifetime, right? Why not use a lower TTL on
> DNSKEY? Less to tweak in the signer.

I agree. Then you would not have to do lowering signature validity
periods at all.

> 4.2.1.2 Breaking the Chain of Trust (2nd paragraph) Isn’t this method
> just breaking your own zone. Not the one that the attacker has? See
> the last paragraph in 4.2.1.

The attacker is still able to spoof the child's zone until the DS is
replaced in the parent, yes.

> 4.2.1 and 4.2.2 What happens if both KSK and ZSK are compromised? In
> most deployments they are probably stored in the same location.

You follow both guidelines described in 4.2.1 and 4.2.2?

> 4.2.3 Compromises of keys Anchored in Resolvers (1st paragraph) 
> Shouldn’t we think the DNSSEC deployment in the root as successful?

Removed the line "For instance, if DNSSEC is successfully deployed...".
But I still think this section has value.

> 4.3.1 Initial Key Exchange I also think that it should be possible to
> send in a DS RR for which there is no DNSKEY in the child zone. I
> know that there are registries that disallow this and others allow
> this. The reason is to not limit any (future) rollover mechanism.
> What we could say is that there should be at least one of the DS RRs
> pointing to a DNSKEY.

Yes.

> 4.3.2 Storing Keys or Hashes (2nd paragraph) Why would storing the
> DNSKEY help troubleshooting, from a registry perspective? If it were
> to debug the conversion from DNSKEY to DS at registry level, then
> that would not be an argument to storing DNSKEY for troubleshooting,
> you would need the DNSKEY anyways.

I don't seem to understand what your point is here...

> 4.3.3 Security Lameness (2nd paragraph) No, the parent should allow
> DS RR pointing to non-published DNSKEY. We should not limit any
> (future) rollover mechanisms. There should of course be at least one
> DS pointing to one DNSKEY.

The section does not prohibit it. It actually mentions the rollover
scheme that may be used.

> 4.3.4 DS Signature Validity Period (2nd Paragraph) It probably does
> not matter how low the period is set in the parent’s policy. Some few
> hour or minutes is enough for an attacker to do damage. Long time
> before the child even considers switching the DS RR.

Do you want to suggest text that should be included into this section?

> 4.3.4 DS Signature Validity Period (3rd Paragraph) Is a period
> between a week and months a good compromise between the operation
> constraints of the parent and minimizing the damage for the child?
> You can do a lot of things during these months…

You are arguing that the upper limit of months should be a lot lower.
That makes sense. Do you have suggestions?

> 4.3.4 DS Signature Validity Period (4th Paragraph) Lower TTL does not
> help against replay attacks.

But it does reduce the damage of a successful replay attack.

> 4.3.5 Changing DNS Operators (1st paragraph) This is not the
> definition of a thin registry. It is a definition of a
> registry-registrar model.

ok.

> 4.3.5.1 Cooperating DNS operators Isn’t the Double-DS method better
> than the double signature KSK rollover in this case? You only share
> DNSKEY RRset with each other. Not sharing signatures.

If the registry and registrars for security lame DS records, then yes.
I will add text.

> 4.4.1 Time Considerations (2nd bullet point) Ok, this means that you
> are reusing the signature up to the point where there is only one
> maximum zone TTL left. If your signing or distribution system breaks
> down, then you only have that time to fix it. Can you fix your system
> within these few hours? Is four days more reasonable? See 4.4.2.2

Yes, will add the operational havoc consideration here too.

> 4.4.1 Time Considerations (3rd bullet point) But it is ok to have 0s
> or 1s TTL for RR that are in the leafs of the DNS tree, right?

Perhaps. You want that in the document?

> 4.4.1 Time Considerations (4th bullet point, 7th paragraph) The SOA
> expiration timer should not be compared with signature validity
> period, but with the refresh period (- resign period).

Ok.

> 4.4.2.2 Minimum Value (last paragraph) I would like to have more text
> about clock skew. It is important to talked about this since time in
> DNSSEC is not relative but absolute. E.g. that one hour for inception
> offset is ok, because if the clocks are more skewed than that, then
> other stuff will break down in your infrastructure.

Do you want to provide text?

> 4.4.2.4 Other timing parameters in a zone This text conflicts with
> the text in 4.4.1 (4th bullet point, 7th paragraph). Here you want
> the SOA expiration to be greater than the signature validity period.

Should be equal to or lower than Refresh period.

> 5.3.2 NSEC3 Iterations (2nd paragraph) You (NLnet Labs) recently
> published a report where large number of iterations made the name
> server less responsive. How would you compare the recommendation in
> this draft with the result from your report?

The report was about the impact for name servers and validators in a
worst case scenario: all NXDOMAINs, very high iteration value. The
conlusion was that name servers dictate these parameters but are
affected the most as well. Because of being worst case scenario
research, I am not sure if the conclusions would fit into 4641bis.

> 5.3.3 NSEC3 Salt (3rd paragraph) You recommend doing re-salting at
> the same time as ZSK rollover. But it is not required to drop all
> signatures at once during a ZSK rollover. This can be a smooth
> transition determined by the refresh period.

ok.

> Appendix A – Key Size Yes in RSA you use the modulus size to
> determine the key size. But it does not apply to other algorithms.

ok.

> Appendix A – Refresh Period New definition: The time before the
> expiration of the signature where it is not reused anymore.

ok.

> Appendix C Move this to the key timing draft.

Consensus was that tables should stay.

> Finally: You are missing text about standby keys. Used to speed up
> the rollover in case of an emergency. But also as part of your
> disaster recovery, when you have lost access to your keys and the
> backups cannot be restored. This is how you do it: 1. Generate
> standby KSK and ZSK. Store them safely. 2. Prepublish standby ZSK in
> zone. 3. Prepublish DS of standby KSK in parent zone. 4. You have a
> disaster. 5. Create a new datacenter and import the standby keys. 6.
> Postpublish old ZSK in zone (fetch it from a secondary somewhere). 7.
> Sign and publish zone. 8. After "some" TTL remove old ZSK and old DS 
> 9. Continue with normal operation.

Ok.

Thanks for the extensive review.

Matthijs

---

From: Rickard Bellgrim <[email-masked]>
Date: Tue, 22 Feb 2011 14:52:45 +0100

>  removed or replaced with a new signature.

Ok

> effectivity periods of months, years and even decades.

Ok

> I do agree that 'on-line HSMs' marginalizes the argument in favor of the

Ok

> value. Do you want to start the discussion of 12 months now? ;)

Lets have another email thread about that :)

> It is NOT RECOMMENDED in 4034, so I think the should is sufficient here.

Ok

> required to follow these guidelines?

We do not need to follow this, but it is good to have information from crypto experts.

> Should that comparison be removed as well?

It is good as a reference on how strong RSA is compared with a symmetric key. But it would be more useful if there was a comparison between e.g. RSA and ECDSA. But ECDSA for DNSSEC is only a draft. So keep the text for now.

> It says typically. I am inclined to say that we do not have to go into

Ok

> But such notation might be to vaguely for operators.

Yes, that was a copy of the text from RSA. It is just a reference for my argument that signing gets eight time slower and not four times.

> Added ', or any other mechanism that runs at a regular interval'.

Ok

> regular update mechanism. Do you?

The ZSK needs to be on-line. The KSK can be off-line.

> arbitrary (like Jelte pointed out as well).

Yes, ok.

> You follow both guidelines described in 4.2.1 and 4.2.2?

Ok

> I don't seem to understand what your point is here...

This section is about whether a registry should accept DS or DNSKEY from the registrar. And one of the arguments for receiving the DNSKEY was that it can be used for debugging. What do you want to debug?

The only thing you can debug within the registry with the help of the DNSKEY, is in fact the conversion from DNSKEY to DS. But that is just a self fulfilling argument.

E.g:
"We want to receive the DNSKEY and not the DS, because we can then debug the conversion from DNSKEY to DS"

> Do you want to suggest text that should be included into this section?

We probably can keep the original text. It at least tells the reader to think about this.

> That makes sense. Do you have suggestions?

We probably can keep the original text. It at least tells the reader to think about this.

> But it does reduce the damage of a successful replay attack.

Ok

> Perhaps. You want that in the document?

It might depend on the implementation. Maybe the BIND or Unbound people knows more about this.

> Do you want to provide text?

From:
   "Note that in the figure the validity of the signature starts shortly
   before the inception time.  That is done to deal with validators that
   might have some clock skew."

To:
   "Note that in the figure the validity of the signature starts shortly
   before the signing time.  That is done to deal with validators that
   might have some clock skew. The inception offset should be
   chosen so that you minimize the false negatives to a reasonable
   level."

> Should be equal to or lower than Refresh period.

Yes. My comment "Here you want the ..." should have been written like this "The draft now say: It is advised to set the SOA expiration to a value greater than the signature validity period."

> research, I am not sure if the conclusions would fit into 4641bis.

But it sounds quite high to follow the recommendation of choosing two-thirds of the maximum from the values 150 (1024 bit), 500 (2048 bit), and 2500 (4096 bit). A DDoS attack could query for domains that does not exist. You e.g. only get 50 % performance on NSD with the recommended value for 1024 bit keys and 25 % with the values for 2048 bit.

// Rickard

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 23 Feb 2011 10:11:48 +0100

Hi Rickard,

> We do not need to follow this, but it is good to have information from crypto experts.

True. But my point is that NIST is a guideline for local policy. This
document targets a larger audience.

Ok.

Ok.

> "We want to receive the DNSKEY and not the DS, because we can then debug the conversion from DNSKEY to DS"

So should we remove the paragraph? (The section will just recommend
storing DS records, and optionally DNSKEY records (e.g. if the
registrars don't allow for uploading DS records).

> It might depend on the implementation. Maybe the BIND or Unbound people knows more about this.

I guess we could say that data at the leafs has less impact on recursive
nameservers than data at delegation points (regarding frequent
verification).

Ok.

> But it sounds quite high to follow the recommendation of choosing two-thirds of the maximum from the values 150 (1024 bit), 500 (2048 bit), and 2500 (4096 bit). A DDoS attack could query for domain…

Ah ok. The report does point out that the half performance count on
nameservers (or at least NSD) in worst case scenarios is about 100
iterations, regardless of the key size. So perhaps the recommendation
should in 4641bis should take that into account.

Best regards,

Matthijs

---

From: Rickard Bellgrim <[email-masked]>
Date: Wed, 23 Feb 2011 11:27:32 +0100

Ok

> registrars don't allow for uploading DS records).

Yes, but the second part of the paragraph:
   "Having an out-of-band mechanism, such as a registry
   directory (e.g., Whois), to find out which keys are used to generate
   DS Resource Records for specific owners and/or zones may also help
   with troubleshooting."

is more relevant and helpful. Maybe it can be used in another context in the draft. Because you could also display the DS RRs in the Whois.

Ok

> should in 4641bis should take that into account.

Yes

// Rickard