Subject: [DNSOP] Comments on RFC4641bis

From: Rickard Bellgrim <[email-masked]>
Date: Mon, 8 Nov 2010 17:51:23 +0100

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.

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.

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.

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.

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.

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

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?

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.

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

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.

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

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?

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.

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

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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…

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

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.

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.

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

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?

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

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.

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.

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?

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.

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.

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

Appendix C
Move this to the key timing draft.

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.

// Rickard

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2010 12:23:16 -0500 (EST)

> 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 ca…

Which HSM and which openssl version on what type of computer? A decent quadcore outperforms
an HSM in my experience.

> 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.…

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)

> http://csrc.nist.gov/groups/ST/toolkit/documents/draftSP800-131_June_11_2010.pdf

key size depends on key usage. The NIST SP (if I remember correctly) lists 1 validity time for both volatile signatures
and long term encryption. In fact, talking to cryptanalists, the 10 years could even be extended, but it was used as a
very conservative number.

> 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 wonder how different implementations handle this case......

> 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.

If you already know the DNSKEY (because you have the DS record), what would be the use of not already
publishing that DNSKEY? If the "DS update" mechanism would be compromised (eg webgui at registry) then
this might allow an attacker to spoof a zone? Verification that the DNSKEY is actually there would
offer additional protection. I think it is better for resolvers not to have to try too many bogus trust
paths by adding "bogus" DS records.

> 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 refre…

I thought you would always have the new ZSK sign all the zone data, and just keep the old ZSK for cached
sigs? So in that case, yes you always drop all signatures during a ZSK rollover (on the signer, TTL's and
SigMax will cause a spread out expiry of the old sigs on caching validating resolvers)

> 9. Continue with normal operation.

I find this very odd. You publish "bad data" just because you might have a bad backup? It seems like
outsourcing your responsibilities, at the cost of everyone's resolvers needing to handle a bogus DS
record. And why would the disaster not destroy the standby keys? And if you have a safe method for
the standby keys, why did you not use it for the current keys as well, thereby preventing the (DNS)
disaster.

Paul

---

From: Roy Arends <[email-masked]>
Date: Mon, 8 Nov 2010 18:33:47 +0000

> Which HSM and which openssl version on what type of computer? A decent quadcore outperforms

Hi Paul,

I think, in general, specs for single purpose dedicated hardware is difficult to be compared to general purpose hardware perform a single task. You'd need to be able to weigh all variables. Apples and oranges really. 

An HSM can be designed to give you speed, http://bit.ly/9cPEDS

It might not be faster than an cluster of general purpose hardware of course.

> and long term encryption.

It doesn't.

> In fact, talking to cryptanalists, the 10 years could even be extended, but it was used as a

What I understand from that NIST recommendation: 1024 is safe until 2010. RSA 1024 bit signature generation is deprecated between 2011-2013. Deprecated means that the use of the algorithm and key length is allowed, but the user must accept some risk. RSA 1024 bit signature validation is 'legacy use' after 2010. Legacy use means that the algorithm or key length may be used to process
already protected information. I have no idea if this is liberal or conservative. I found it hard to get anyone underwrite its conservativeness, most folks say 'yep, sounds about right to me'. Better safe than sorry.

> I wonder how different implementations handle this case......

I have tested chains of trust (with BIND9 and unbound) in the past and noticed that its validity did not depend on the SEP bit being clear or set. 

> publishing that DNSKEY?

DNSKEY RRSet size might be an issue. 

> SigMax will cause a spread out expiry of the old sigs on caching validating resolvers)

When I transition from old to new key, it would be nice to spread the load (generating new signatures over the entire zone with the new key), while keeping One Signature per RRSet (for response size). That means that for some serial number, some NSEC3 records have signatures with the old key, others have signatures with the new key. Especially handy for very large zones.

I think its best to see re-salting as an individual event, and not tie it to some other event. 

> record.

Validation doesn't really work that way, right? You have a chain of DS's+KEYS you want to validate. A bogus DS is not in that chain. Maybe validators validate differently these days. 

Also, 'outsourcing your responsibilities' is a bit harsh. This is just another way to limit damage. In that sense they are taking their responsibility.

Note that I'm not a big fan of standby keys. I think a little bit of redundant setup goes a long way, and has the same effect.

If you keep the DNSKEY ttl down a bit, the time needed for this key to be pre-published goes down with it. You can then consider not to pre-publish that standby key at all, and we're back to the bogus DS argument.

> And why would the disaster not destroy the standby keys?

Because you keep them 'elsewhere'.

Roy

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 08 Nov 2010 22:10:08 +0100

Hi Rickard,

> Move this to the key timing draft.

But the key timing draft does not take into account algorithm rollover.

Best regards,

Matthijs

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 09 Nov 2010 07:41:32 +0800

> I have tested chains of trust (with BIND9 and unbound) in the past and noticed that its validity did not depend on the SEP bit being clear or set.

If they did, they would not follow the spec ;)

A SEP key can be a ZSK too. The only value of the SEP flag is for operators 
and/or tools, validators should ignore it.

Whether or not a key is a ZSK, a KSK, or both, is, from the validator's point of 
view, defined by whichever signatures you see. So yes, if you can make arbitrary 
signatures with a compromised key, you can 'change' its KSK/ZSK status, and no 
validator should be able to notice. But well, you can make arbitrary signatures 
anyway...

Jelte

---

From: Rickard Bellgrim <[email-masked]>
Date: Tue, 9 Nov 2010 06:26:24 +0100

> Which HSM and which openssl version on what type of computer? A decent quadcore outperforms

The Sun SCA6000 gives you 13 000 sig/s for a 1024-bit rsa. And you can cluster e.g. three of them to get 40 000 sig/s

The test server is perhaps three years old.
Sun Microsystems Sun Fire X4100 M2
Processors: 2 x Dual-Core AMD Opteron 2793 MHz

openssl speed rsa1024 -multi 4
8333.3 sig/s

(4 threads was the fastest combination)

Conclusion: The speed of an HSM is comparable with doing it in software.

> record. It's not fully in your control, so there is some possible delay (and you NEED a monitor to avoid a bad rollover)

Yes, the affect the rollover time, but this does not limit your choice of the signature validity period for the KSK. If you read the statement in the draft, then it sounds like the ZSK can have a shorter signature validity period because it does not interact with the parent.

> very conservative number.

Yes, I used the numbers from "Table 2: Digital Signatures Security Strength Transitions"

Just wanted to point out that there are people who do not think 1024-bit keys are safe for at least the next ten years.

> I wonder how different implementations handle this case......

As the others say, the SEP bit does not prevent a key from being used for signing/validating other zone data than the key set.

The draft now just follows the regular definition of a KSK, but it does not limit the actions of the attacker to only sign the key set. (and if there was a limit, then the attacker off course includes its own new ZSK in the key set). So when describing what an attacker could do, we should describe what it could do rather then what a normal signer should do.

> If you already know the DNSKEY (because you have the DS record), what would be the use of not already

As Roy said, size of the DNSKEY RRset.

> If the "DS update" mechanism would be compromised (eg webgui at registry) then
> this might allow an attacker to spoof a zone?

If they can comprise the DS update mechanism, then they probably can do stuff to the NS.

> Verification that the DNSKEY is actually there would

Are they bogus if there is no DNSKEY?

The reason that I want this is for may standby key mechanism below, where you just publish the DS, but not the DNSKEY of the KSK.

> SigMax will cause a spread out expiry of the old sigs on caching validating resolvers)

I agree with Roy's answer.

> the standby keys, why did you not use it for the current keys as well, thereby preventing the (DNS)

It might also be that you signing system breaks down, or that there is a bug in your HSM:s which prevent you getting access to the keys.

---

From: Roy Arends <[email-masked]>
Date: Tue, 9 Nov 2010 09:35:35 +0000

On Nov 8, 2010, at 11:41 PM, Jelte Jansen wrote:

> A SEP key can be a ZSK too. The only value of the SEP flag is for operators and/or tools, validators should ignore it.
> 
> Whether or not a key is a ZSK, a KSK, or both, is, from the validator's point of view, defined by whichever signatures you see. So yes, if you can make arbitrary signatures with a compromised key, you can 'change' its KSK/ZSK status, and no validator should be able to notice. But well, you can make arbitrary signatures anyway...

That is exactly what I meant. Apologies if that wasn't clear.

When I tested this, I tested with all possible combos in a single chain: all zsk, all ksk, combinations of both, etc.

Roy

---

From: Rickard Bellgrim <[email-masked]>
Date: Tue, 9 Nov 2010 10:40:49 +0100

> But the key timing draft does not take into account algorithm rollover.

Yes, that is true. Maybe high level description should go into this document. And the details (timing) of the algorithm rollover should go into the timing draft. This draft is about operational issues. The timing draft is for implementation.

// Rickard

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 09 Nov 2010 12:16:37 +0100

Hi Rickard,

On 11/09/2010 10:40 AM, Rickard Bellgrim wrote:
> 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.

With multiple algorithms, multiple DS RRs must successfully point to a
DNSKEY (that signs the DNSKEY rrset).   A DS for every
signing-algorithm-number present in the DS RRset must succeed.

This also affects the disaster plans.  In an algorithm rollover you must
have disaster recovery keys for the new algorithm as well, and add and
remove the disaster-recovery keys and DSes at the same time as the
normal keys and DSes of that algorithm.  If you have your disaster
recovery key a different algorithm, then its DS publication would be an
invalid chain of trust (for that algorithm).

Best regards,
   Wouter

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 10 Nov 2010 08:02:16 +0800

Thanks for the very detailed review!

Due to family circumstances I cannot be at the dnsop meeting and I will not have time to review all the points you made before thursday.

However, since you highlighted this point in the hallway, I would like to ask the working group for guidance.
> 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 tha…

From our hallway conversation I understand you mostly refer to the tables and that the fact that text relies on them.

We have argued about this during our last face2face meeting. And my take-away from that discussion was that the timings draft was supposed to be guidance for implementors, while this draft is targeted to operators. My understanding was that the tables where a helpful addition (a picture says more than a thousand words). 

Quickly going back to the minutes I noticed that the above argument (and a counter-argument resembling yours, by Andrew) was captured. But that the room made 'useful sounds' which I took for consensus with keeping the tables in.

I would like to get confirmation from the chairs whether that was is the correct interpretation of the discussion instead of revisiting this issue.

There may be some more points in your review that are revisiting issues that I think we closed. Unless the chairs instruct me otherwise I am tempted to keep closed issues closed.

That said, I really appreciate your detailed review.

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam