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

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 13:03:58 +0200

All,

[email-masked] wrote:
> 	Title           : DNSSEC Operational Practices, Version 2
> 	Author(s)       : O. Kolkman, M. Gieben
> 	Filename        : draft-ietf-dnsop-rfc4641bis-01.txt
> 	Pages           : 38
> 	Date            : 2009-03-06

I had a look through this and have a few comments.

First, key length:

                   An attacker breaking a 1024-bit signing key would
   need expend phenominal amounts of networked computing power in a way
   that would not be detected in order to break a single key.  Because
   of this, it is estimated that most zones can safely use 1024-bit keys
   for at least the next ten years.  A 1024-bit asymmetric key has an
   approximate equivalent strength of a symmetric 80-bit key.

(Typo: "phenominal" -> "phenomenal")

This section does not match up with the tiny bit of crypto research I've
done. The Wikipedia entry on key lengths references an RSA and a NIST
publication, both of which suggest 1024 bits not be used after 2010:

http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths

So the "ten years" recommendation goes about 8 years beyond what
cryptographic experts suggest.

Perhaps one could suggest 1024-bits is enough for a ZSK that rolled
relatively frequently. However, looking at the RSA page, we see:

    Arjen Lenstra and Eric Verheul’s methodical estimates [LV01] give
    quite similar results for the security of 1024-bit RSA keys. In one
    model, they project that in the year 2009, a machine costing about
    $250 million could factor a 1024-bit RSA key in a day — so a $10
    million machine would take just under a month.

This seems to imply that one would need to roll a ZSK every few weeks to
 feel safe from cryptographic attacks if using 1024-bit keys.

Second, private key storage:

   It is recommended that, where possible, zone private keys and the
   zone file master copy that is to be signed be kept and used in off-
   line, non-network-connected, physically secure machines only.

Then later...

   In general, keeping a zone file off-line will not be practical and
   the machines on which zone files are maintained will be connected to
   a network.  Operators are advised to take security measures to shield
   unauthorized access to the master copy.

The whole idea of offline storage for the zone itself is so fantastical
I hardly know where to begin! Has there ever in the history of DNS been
a zone where the master copy is only stored in a computer is not network
connected?

Of course it is theoretically possible. But I think at most a single
paragraph mentioning the possibility is enough to insure that the people
who have this level of paranoia about their DNS data will be able to let
their fevered imaginations run wild, without wasting the time of people
with actual deployments. :)

It might be more useful to recommend HSM - or at least encryption - for
private key data. I didn't see any references to this, and AFAIK
everybody does it (or feels guilty for not doing it).

Cheers,

--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 10:51:52 -0400

>The whole idea of offline storage for the zone itself is so fantastical

An artifact in the DNSSEC concept stemming from the days when DNSSEC 
was discussed in the Security Area of the IETF.  Fantastical is a 
good word.

>everybody does it (or feels guilty for not doing it).

I can't rationalize a justification of HSMs for DNSSEC.  I mean, 
outside of "doing it because we can say we do it" I think it is 
overkill (in some environments), and feel more guilty spending money 
on something I see as window dressing.

This comes from the observation that the contents of the database 
sourcing the zone (whether a commercial-like database or a vi'd file) 
are more critical than the private key.  (If) They are sufficiently 
protected and I'll just keep the private key behind the same 
fortifications.  So, what does an HSM add?

(Really, I'd like to know...;))

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 21 Apr 2009 17:03:23 +0200

> fortifications.  So, what does an HSM add?

I think the general idea is that if you have to edit your zone because
it was tampered with, chances are that nobody will notice (or
everybody will attribute it to routine maintenance).  If your key is
compromised and you have to replace it out of schedule, you might have
got some explaining to do. 8-)

Of course, this isn't a strong argument in favor of HSMs.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 11:25:59 -0400

>Of course, this isn't a strong argument in favor of HSMs.

(Changing the subject to "HSMs" because this is more about that than 
the draft.)

Before the thread goes too far, I should say that I'm thinking of 
this as an operator of a zone that delegates to other entities.

In such a situation, diddling inappropriately with the database means 
"*some*body *will* notice" and that somebody is "above my 
management."  (I.e., customers.)  Diddling with the private key is 
something I only need to raise up to the management.  (If that's any 
metric.)

Rolling a key is much less problematic (especially ZSKs) than having 
to clean up a "hijacked" delegation.  Even a KSK isn't that bad - if 
the parent is signed and I never promise my KSK as an SEP.

I once used this argument in a security conference I did a panel on 
some years ago.  "If I am the operator of a zone and do something to 
mess up the private key so bad my regulator wants to fire me, the 
regulator does not come for the private key, instead they come for 
the database."  My concern is first the database over the key, it's 
what matters in the event of catastrophic organizational failure.

 From that, it's a matter of "fate sharing."  What ever I do to 
protect my most vital element (database) can be used to protect other 
things as well, including the key.  I know - what about insiders 
mucking with the key?  Well, what about the insiders mucking with the 
database?  Fate sharing.

This isn't a "death-knell" for HSMs in my mind.  There are 
environments where they are useful.  It's just in an environment 
which already has a lot of "fortification" an HSM may not be an 
improvement, other than to claim "we do it."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Apr 2009 17:32:13 +0200

On Tue, Apr 21, 2009 at 11:25:59AM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 60 lines which said:

> My concern is first the database over the key, it's what matters in
> the event of catastrophic organizational failure.
>
> From that, it's a matter of "fate sharing."  What ever I do to protect my 
> most vital element (database) can be used to protect other things as 
> well, including the key. 

But the risk for the key is not only people modifying it, it is simply
people *reading* it (a concern which also exists for the database but
is much less important). 

I have no practical experience with HSMs but, in my mind, the
interesting thing is that they guarantee noone will read the key
without an authorization (that's quite unlike the database where you
certainly prefer a few unauthorized looks to a complete loss).

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 11:45:18 -0400

>certainly prefer a few unauthorized looks to a complete loss).

Jokingly said, I don't mind someone reading the key, it's the forging 
I mind. ;)

Suppose that I tightly constrain who reads the database.  I can 
constrain reading permissions down to the same set as those who can 
make changes, or even access where ever the private key is stored.

What might be confusing is that the general public can "query" the 
database via DNS or WhoIS or EPP.  But that's not really the database 
query, responses are the affect of what's in the database.  (For 
example, a DNS query can't trigger getting the creation data of the 
record, while WhoIs can.)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Apr 2009 12:00:40 -0400

On Tue, Apr 21, 2009 at 11:45:18AM -0400, Edward Lewis wrote:
>
> Suppose that I tightly constrain who reads the database.  

Suppose you do.  Then you still have the problem of escalation attacks.  

HSMs are designed to make such attacks impossible: the key simply
won't come out.  That's a better answer than, "I've set it up so that
just about nobody can get to the key", since privilege escalation in
database systems is exactly the place good attackers work.  I notice
in passing that a certain large company who recently bought Sun no
longer makes "unbreakable" claims loudly and in public. 

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 18:01:57 +0200

Stephane,

> certainly prefer a few unauthorized looks to a complete loss).

This is the key point IMHO.

AIUI, the attack vector that HSM are designed to protect is that someone
makes a copy of your key signing material without you knowing about it.
Once they do that, they can spoof replies until such time as you roll
your key.

If an unauthorized person modifies the contents of the database backing
your zone, you may or may not know about it, but an observant customer
will at least notice that the data has changed.

So the two are not totally equivalent.

Having said that, I agree that HSM hysteria is a bit overblown, and that
the actual DNSSEC signing is very, very unlikely to be the weakest link
in DNS security in any organization.

--
Shane

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Apr 2009 09:54:39 -0700

>cryptographic experts suggest.

We should be making our recommendations on more than a tiny bit of crypto research. You can read the NIST recommendations directly, for example. They say pretty explicitly that they apply only to US federal use. They also do not suggest that 1024 in 2011 is actually expected to be broken. (Clearly, we should add a pointer to NIST SP 800-57 to this document, even though it seems unlikely that almost anyone will actually read it.)

As I have said repeatedly, the best known attack as of today is against the equivalent of a 700-bit key. NIST's recommendations assume that it is very difficult to change a key as the attacks get better (as they surely will); that assumption is completely false for DNSSEC.

>    Arjen Lenstra and Eric Verheul's methodical estimates [LV01] give
>    $250 million could factor a 1024-bit RSA key in a day - so a $10

...assuming that you feel that attacker would spend even a million dollars to break your key. This line of logic completely discounts common sense, however. Which is more valuable to an attacker: the ability to temporarily spoof DNS responses in your zone, or the ability to masquerade as any secure web site they want to?

I'm not advocating that people use 1024 bit keys; that's up to them. If someone wants to use 2048-bit keys that take about four times as much effort to sign and verify, that's great. However, those people should make decisions based on facts about DNSSEC deployment, not extrapolations from estimates that are both speculative and based on key usage that is not applicable to DNSSEC.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 13:09:25 -0400

At 9:54 -0700 4/21/09, Paul Hoffman wrote:
>However, those people should make decisions based on facts about DNSSEC
>deployment, not extrapolations from estimates that are both speculative and
>based on key usage that is not applicable to DNSSEC.

Paul, you are right.  But for the last decade plus, extrapolations 
and estimates  based on speculation and false analogies is all we've 
had to go on. ;)

(This is rooted in my mic comment "I've never seen anyone admit to be 
a cryptographer on tape[0].")

[0] - As in audio or video tape, which has been outmoded by MP3's and 
DVDs and such.  (My lingo is stuck in 1983.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 13:22:01 -0400

>longer makes "unbreakable" claims loudly and in public.

Hmmm, this doesn't apply...  To be fair, I don't want to dive into 
the details of what I see.  Thus the justification of my reaction 
here is not going to be convincing.

Trying to fudge around a bit for the justification, the database and 
the key are not linked "in series", they are both are behind the some 
of the same fortifications.  "Breaking the database" security won't 
make getting to the key any easier, i.e., the database does not 
contain the information needed to access the key.

In a way, I figure - "if you can read my private key, I have larger 
issues to deal with."

At the IEPG meeting in, umm, not SF, but in, umm, where was, oh, 
Minneapolis, I mentioned that the "value in protecting the private 
key is a function of the cost of rolling to a new key."  If the key 
is a SEP, it's the cost of rolling it through the trust anchor 
repositories, if the key is a lowly ZSK, then it's more or less just 
the liability for goofing up.  It's not like someone reading the key 
is going to unlock encrypted state secrets and such.

I should add too that the impact of someone reading the key and 
someone reverse-engineering (guessing) the key is essentially the 
same.  The latter is a different cause though - "luck" or weak choice 
of a key pair that succumbs to a key dictionary attack.  (HSMs are 
not there so much for that unless they have an enhanced way to choose 
"random" numbers - which some do advertise.)

I guess the equation is - the cost of an HSM vs. the value of saving 
one's operations from key "exposure."  (Not the same as a forged 
response.)

Sorry if it sounds like I'm just talking in circles.  But I can't see 
the very vulnerability that an HSM addresses as being likely enough 
to be worth addressing given all the other vulnerabilities.

(Finally, my mantra here.  HSMs are not total wastes.  HSMs do add 
value.  But just not universally needed/incrementally valuable.)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Apr 2009 10:29:44 -0700

At 1:09 PM -0400 4/21/09, Edward Lewis wrote:
>Paul, you are right.  But for the last decade plus, extrapolations and estimates  based on speculation and false analogies is all we've had to go on. ;)

To be fair, in the future, we will still have only speculation. We can never predict when significantly better attacks will be created. Nor can we ever be sure that some attacker somewhere has not created a non-public attack. However, we can always be sure that attackers will use their resources against the most valuable vulnerability. Until attackers' resources become so cheap that they can stop discriminating (as is the case with spammers), if there are equivalent attacks that yield better results than those against DNSSEC, they will aim them elsewhere.

We can start ignoring false analogies any time we want.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Apr 2009 13:50:11 -0400 (EDT)

On Tue, 21 Apr 2009, Edward Lewis wrote:

> I mentioned that the "value in protecting the private key is a function of 
> the cost of rolling to a new key."

Plus your legal bill explaining in court over and over again why you were not
legally responsible for costs of the breach. The million dollar question
becomes "If you had used an HSM, would this attack have been possible?".
There are some attacks where you will have to answer "no".

> If the key is a SEP, it's the cost of 
> rolling it through the trust anchor repositories, if the key is a lowly ZSK, 
> then it's more or less just the liability for goofing up.  It's not like 
> someone reading the key is going to unlock encrypted state secrets and such.

No, they just connect to the bogus largebank.com and steal more then your gross
turnover....

> I guess the equation is - the cost of an HSM vs. the value of saving one's 
> operations from key "exposure."  (Not the same as a forged response.)

Key exposure is very similar to unsigned zone data exposure, since if you
don't detect unsigned data changes, you will just sign them with your key.
As such, an HSM does not bring you much value per se.

> Sorry if it sounds like I'm just talking in circles.  But I can't see the 
> very vulnerability that an HSM addresses as being likely enough to be worth 
> addressing given all the other vulnerabilities.

The one it mostly protects against is someone stealing a copy of the key,
and signing items not local to you but to their targets. You will not
experience anything, and it might be hard for you to detect you lost your
key unless you detect the intrusion. But rogue signed data never comes
back to you. When using an HSM, attackers have to maintain access to the
compromised data and any rogue signed data lives within your own infrastructure
and could be more easilly detected (when complains come in about the rogue
signed data)

I am tempted to lean towards using a KSK in an HSM, and using the ZSK without
an HSM, due to the speed limitations of the HSM's signing bulk data, and the
relative ease of replacing the ZSK, together with current strong security on
the unsigned data and servers currently in use by TLDs.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Apr 2009 13:59:49 -0400 (EDT)

On Tue, 21 Apr 2009, Edward Lewis wrote:

> Rolling a key is much less problematic (especially ZSKs) than having to clean 
> up a "hijacked" delegation.  Even a KSK isn't that bad - if the parent is 
> signed and I never promise my KSK as an SEP.

Then you put your vulnerability period during emergency key rollover in the
hands of the RRSIG lifetime of the parent. That lifetime is probably even
longer then the time for the attack(er) to make it to CNN's broadcast that
hopefully warns your custmers.

> This isn't a "death-knell" for HSMs in my mind.  There are environments where 
> they are useful.  It's just in an environment which already has a lot of 
> "fortification" an HSM may not be an improvement, other than to claim "we do 
> it."

I do agree mostly with this statement. See previous email.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Apr 2009 14:09:27 -0400

On Tue, Apr 21, 2009 at 01:22:01PM -0400, Edward Lewis wrote:

> same fortifications.  "Breaking the database" security won't make getting 
> to the key any easier, i.e., the database does not contain the 
> information needed to access the key.

If the database does not contain the information needed to access the
key -- which actually means "does not contain the key", since if the
database contains the key it contains the information needed to access
the key -- then you have just built your own HSM-like device (except
that it implements some of the components in software instead).  Now
your only problem is trying to prove that your system is as secure as
the alternative, which is just buying an HSM.  HSMs aren't just
expensive because of the unusual hardware they contain.  The testing
of them to prove they meet all those big standards most of us haven't
read is expensive and time consuming (and risky, if you find your
device fails).

If the database _does_ contain the key, then the only question is
whether there is an escalation attack that can get an attacker the
privileges needed to access the key.  One such escalation attack, of
course, is "get hired and have access to the superuser account."  I'm
aware of how the accounting systems catch such access.  I'm also aware
of how such access accounting breaks down.

Anyway, I completely agree that this is a cost-benefit analysis that
different sites have to do based on their use cases.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 21:50:53 +0200

> In a way, I figure - "if you can read my private key, I have larger

The problem is that without an HSM then 'you' becomes open to all kinds
of social attacks.

When we looked at the problem of disgruntled or bribed employees, HSM
(or the equivalent) was the only logical answer. Otherwise the private
key can be copied off, probably without your knowledge, by trusted staff.

Not necessary in all scenarios, clearly! But I think a paragraph or two
in the RFC to alert people to the possibility makes sense.

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Tue, 21 Apr 2009 22:07:08 +0200

Paul,

> ...assuming that you feel that attacker would spend even a million dollars to break your key. This line of logic completely discounts common sense, however. Which is more valuable to an attacker: t…

The same RSA-cracker that our evil-doers dropped $10 million on to hack
web SSL will work nicely for RSA DNSSEC, thanks!

> I'm not advocating that people use 1024 bit keys; that's up to them. If someone wants to use 2048-bit keys that take about four times as much effort to sign and verify, that's great. However, those…

I look at it like this:

High-volume and/or high-profile sites are the very ones that will most
likely be attacked, and the ones that should really consider a longer
key length for security. Low-volume and/or low-profile sites don't
really need to care about the computation time expended, because in the
end we're not talking about a lot of bandwidth or cycles in total. (The
computational losers in DNSSEC are, as always, the validating resolvers.
I don't know of any benchmarks showing the cost of relative key sizes
for resolvers though, so it's all a bit hand-wavy, but it could be a
real problem.)

While you may not advocate that people use 1024 bit keys, the draft
spends 5 paragraphs advocating 1024 bit keys. I obviously think this is
a misguided recommendation. At the very least we should tone it down a bit.

--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 16:17:09 -0400

>No, they just connect to the bogus largebank.com and steal more then 

Ummm, psst, most banks here are bankrupt. ;)

>I am tempted to lean towards using a KSK in an HSM, and using the ZSK without

I had the same thought at one point.  But...

As far as an HSM as one way to cover my bases in the event of 
litigation, that goes without question - especially when 
hypothetically speaking.  But pragmatically speaking, I haven't seen 
a "proof" I need an HSM.

Yes, I could use some stress in my life, I hear it's a good way to lose weight.

>hopefully warns your custmers.

The problem with revocation in DNSSEC is not limited to issues 
impacted by the choice whether to use an HSM.  E.g., if the HSM uses 
a key that some one else guesses, you have the same problem whether 
you used an HSM or not.  (I guess I suppose it's possible to have key 
dictionary attacks, for example.)

But I suppose that's far flung - I would hope an HSM does a good job 
at randomn number generation.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Apr 2009 16:25:55 -0400

>different sites have to do based on their use cases.

I appreciate the value of having an HSM that complies with public 
certifications and would use one that tipped the cost-benefit 
analysis in it's favor.  Whether or not meeting a public 
certification is desirable is not (just) a technical design point, 
whether or not it is also a good idea.

I started this thread as a reaction to the comment that the subject's 
draft say "useful to recommend HSM" and I wasn't so sure I'd hum to 
that.

What I'm really looking for a convincing argument that I really 
should be using an HSM other than it would make me sleep better in 
meetings, I mean, at night.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Apr 2009 15:13:27 -0700

>web SSL will work nicely for RSA DNSSEC, thanks!

You're welcome. :-) Of course it will. It will also work on all other 1024-bit keys. If you believe that your DNSSEC key is worth more to an attacker than those other keys, then you should use a larger key. Nothing special here.

>key length for security.

Of course. They should also really consider whether or not they will ever get attacked. If not (because attackers will be more interested in other keys), then that is an input to their decision-making. 'Twas ever thus.

> Low-volume and/or low-profile sites don't
>end we're not talking about a lot of bandwidth or cycles in total.

I don't understand this. It is not the end users who will be spending the cycles doing signature validation, it is the validating resolvers.

>(The

'openssl speed rsa1024 rsa2048' is your friend here. On my laptop, signing takes six times longer, but verifying only takes three times longer. Different platforms will give different results.

>spends 5 paragraphs advocating 1024 bit keys.

No, it doesn't. It spends five paragraphs saying "you're probably fine with 1024 bit keys, but consider the consequences". If you have replacement wording, it would be great to see it.

>I obviously think this is

I fully disagree with "tone it down". This is an operational document. Telling operators what they should consider when making policy is *much* better than giving them a summarized number that may not apply to DNSSEC at all. Others may disagree and want a single summarized number; however, in that case, 1024 would apply to more readers than 2048 would. Not letting the reader decide for themselves will lead to either worse security or needlessly wasted CPU cycles.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Apr 2009 22:44:33 -0400 (EDT)

> 'openssl speed rsa1024 rsa2048' is your friend here. On my laptop, signing takes six times longer, but verifying only takes three times longer. Different platforms will give different results.

So do different versions of openssl. 0.9.8k was much slower then
0.9.8i. But openssl-1.0.0beta was faster again for me. As for
dnssec-signzone, the 9.6.1 version seemed much faster for me then
previous versions, ldns-signzone was extremely slow, but I guess that's
why they're working on hsm-signer :)

(all meassures with unsigned zones as input)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Apr 2009 22:59:25 -0400 (EDT)

> key can be copied off, probably without your knowledge, by trusted staff.

You could use something like Shamir's secret sharing scheme[*] to store the
the private key securely outside an HSM. That can give you a 3 out of 5
trusted employees are needed everytime you need the KSK (which you would
not need to have more then once every couple of weeks).  But the costs
of getting people together would probably end up costing a lot more then
an HSM.

Paul
[*] http://point-at-infinity.org/ssss/

---

From: Shane Kerr <[email-masked]>
Date: Wed, 22 Apr 2009 12:24:02 +0200

> You're welcome. :-) Of course it will. It will also work on all other 1024-bit keys. If you believe that your DNSSEC key is worth more to an attacker than those other keys, then you should use a la…

You seem to think that because there are higher-value targets nobody
would ever bother to attack a 1024-bit DNSSEC key. My point is that once
the investment has been made to attack SSL certificates, the tools can
just as easily be used for DNSSEC.

So rather than feel safe because someone else is a nicer target, we
should worry because cracking technology reduces the safety of all keys.

> I don't understand this. It is not the end users who will be spending the cycles doing signature validation, it is the validating resolvers.

When I wrote "in the end", I didn't mean for the end users, I meant "in
the end":

http://www.thefreedictionary.com/in+the+end

As the example says, "All will turn out well in the end." :)

Basically, if it's 3x slower to verify but this means using 30 seconds
of CPU time for all validations in the lifetime of the zone instead of
10 seconds, then we might as well longer keys.

So, to recap:

- People who get a lot of traffic will probably want longer keys because
  they are a valuable target.
- People who do not get a lot of traffic might as well use longer keys
  because the total cost to them and their users will be minimal.

> No, it doesn't. It spends five paragraphs saying "you're probably fine with 1024 bit keys, but consider the consequences". If you have replacement wording, it would be great to see it.

My replacement wording would be simply: "unless you have a reason to
worry about bandwidth or CPU time of validating resolvers, use 2048 bit
keys, because this will be safe for the foreseeable future".

> I fully disagree with "tone it down". This is an operational document. Telling operators what they should consider when making policy is *much* better than giving them a summarized number that may…

I'm not sure how this will lead to worse security, but I agree using
longer keys would result in extra CPU cycles being used.

I don't think this is a waste, really. I think if we recommend 1024 as
the text does, then we'll have to revisit it in 3 or 4 years. I would
prefer to pick a key length that will last a decade or two (pending
quantum computing or suchlike), or at the very least not recommend 1024
so strongly.

--
Shane

---

From: Chris Thompson <[email-masked]>
Date: 22 Apr 2009 12:55:39 +0100

>> At 10:07 PM +0200 4/21/09, Shane Kerr wrote:
[...]
>should worry because cracking technology reduces the safety of all keys.

There are *two* cost figures involved in the hypothetical cracking.
There is the setup cost of the equipment, to which the $10million 
refers, and the incremental cost of cracking a particular key. Even
if the latter is "how long do I have to dedicate my $10million
equipment to cracking this particular key". 

The right model is probably "how much do we have to charge Black Hat, Inc.
per key we crack for them, to make a decent profit?".

-- 
Chris Thompson
Email: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Apr 2009 08:24:35 -0700

At 12:24 PM +0200 4/22/09, Shane Kerr wrote:
>would ever bother to attack a 1024-bit DNSSEC key.

Correct. Why would an attacker waste resources attacking a target with lower value than other targets? This is Security 101.

>My point is that once

And I agreed with that assessment.

>should worry because cracking technology reduces the safety of all keys.

We disagree here. People with targets that are not near the top of the target list can feel safer *and* we should worry because cracking technology reduces the safety of all keys.

Right now, no one has come even close to attacking a 1024-bit key in public. At some point in the future, that will change, either by a researcher doing it, or by a miscreant doing it and being caught. That will be a data point for everyone (DNSSEC zone holders, CAs, organizations with PKIX certificates, and relying parties for all the above) to decide what they should do next about key sizes. Some of those parties will decide before the first public attack; for example, NIST wants to be ahead of the curve and has set a date of Jan 1 2011 for US Federal users. Others may do the same, or might wait for better data.

>10 seconds, then we might as well longer keys.

These kinds of calculations are exactly what I hope zones use when they decide what key length to choose.

>  because the total cost to them and their users will be minimal.

And these are not. I fully disagree that FadSiteOfTheYear.com is a more valuable target than SmallLocalBank.com.

>keys, because this will be safe for the foreseeable future".

That's one option, similar the current 4641. The option that some people think is better is to explain to them what the bandwidth and CPU tradeoffs are, and to explain what is foreseeable.

>longer keys would result in extra CPU cycles being used.

If you don't explain what the options are, operators will pick inappropriate options. Some of those choices will inevitably be for worse security.

>the text does, then we'll have to revisit it in 3 or 4 years.

If you're predicting that there will be public breaking of 1024-bit keys in "3 or 4 years", you may want to justify that prediction, given that we haven't even seen a break that is literally hundreds of times easier.

>I would

Great: pick such a key! The point of the proposed text is to let people pick what is appropriate for them, not what any one of us thinks. If you have evidence that 1024-bit keys are breakable within a few years, that would be valuable to include. In fact, there are literally hundreds of CAs who would want to hear it as well, and we should publish a parallel document covering TLS, IPsec, S/MIME, and so on.

At 12:55 PM +0100 4/22/09, Chris Thompson wrote:
>There is the setup cost of the equipment, to which the $10million refers, and the incremental cost of cracking a particular key. Even

Exactly right. (Well, the third question is whether or not the guesses of $10 million still stand up.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Apr 2009 11:54:13 -0400 (EDT)

> the text does, then we'll have to revisit it in 3 or 4 years.

Is this for ZSK or KSK? Because if you pick equal sizes, then both would be
equally vulnerable to the same brute force attack, and often cycling a ZSK of
equal size to the KSK key does not make much sense - the attackers would
just ignore the ZSK and go for the KSK instead. So using a 2048 ZSK sort
of implies using a larger KSK. Unless you keep the ZSK for 6 months or so.

Paul

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 01:35:31 +0200

Paul,

> of implies using a larger KSK. Unless you keep the ZSK for 6 months or so.

Good point. I was only ever considering KSK key length.

I kind of assume everyone will use automated ZSK rolling, and that ZSK
will get rolled fairly frequently, so shorter keys make sense.

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Apr 2009 11:32:02 -0400 (EDT)

On Thu, 23 Apr 2009, Paul Wouters wrote:

> So what's your take on 1024 ZSK keys? Are they good for 1 month? 6 months?
>
> I'm trying to come up with justified numbers, but everyone keeps claiming
> they're not a cryptographer :)
>
> But I'm having lunch with one today....we'll see

So interestingly, the cryptographer (Ian Goldberg) started out with saying
that you should not ask cryptographers either, but instead should ask
mathematicians and hardware designers.

He started of saying that there is a huge difference in using a key for
signing, and using a key for encrypting. The first only has to be unbreakable
for the limited time the signed message is still useful to someone else,
where as the encrypted message probably needs to be able to be unbreakable
for much longer, until the secret itself becomes unvaluable. So the
required resilience for signing keys is in the order of years, while for
encryption keys this will be meassured in the order of decades.

So when looking at things like the NIST recommendation for not using 1024
bit RSA keys anymore, you have to realise this difference. Once a signing
key is retired, is has no value left in it.

This also means that the safe period for a signing key is much easier to
adjust (up and down) then the safe period for an encryption key, since
you yourself can decide almost instantly when to retire a signing key.

Pages such as http://www.rsa.com/rsalabs/node.asp?id=2004 take this into
account somewhat, but still mostly compares RSA keysizes with encryption
cipher keysizes (eg with AES) and assume the data needs to be unbreakable
for decades instead of for years.

Ian Goldberg said he would be shocked if 1024 RSA keys would be breakable
within years. And that if space (in the dns packet) considerations were
an issue, 1024 should be fine. And importantly, because it is a signing
key with no need for future safe guards, easy to adjust once unexpected
mathematical (or technological) advanced are made. So we can be
conservative and take DNS packet size and validating resolver resources
into account.

So it seems to me that using 1024 bit RSA keys for ZSK, and 2048 bit
keys for KSK, assuming RFC 4641 rollover periods, are still many orders
of magnitude safe for our use within the DNSSEC realm. In fact, it
seems RFC4641, as written in 2006, is still extremely conservative in
its estimates two and a half years after its publication date.

Note that the same does not apply for DSA. As I understood it, DSA
requires the use of some randomness for each signature, and the errors
in the random number generator are cummulative when attempting to crack
this key.  In other words, the more data you sign, the more vulnerable
you become to the tiniest imperfection in your HWRNG.

Paul
(sorry if all of this was already discussed in 2006)

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2009 09:42:55 -0700

Thanks, Paul.

>its estimates two and a half years after its publication date.

That is fine, but so is 1024 bit KSKs. The text in RFC 4641bis makes it clear that KSKs should be rollable in case of an emergency; the effort to do so is greater, but not that much greater, than rolling a ZSK.

The WG should decide which seems better to recommend:

a) KSKs longer than ZSKs because KSKs are thought of as needing to be stronger

b) KSKs the same strength as ZSKs because neither should be weak enough to be attacked

I prefer (b), but (a) keeps coming up in this discussion.

>you become to the tiniest imperfection in your HWRNG.

That's not the problem. If the per-message random number used in signing is found, the private key is disclosed; there is no requirement for a cumulative error. That has not proven to be a problem for DSA in its current uses, but the random number generator *must* always be a concern.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 24 Apr 2009 19:29:34 +0200

> I prefer (b), but (a) keeps coming up in this discussion.

The dimension I'm usually missing in these discussions is the lifetimes of keys
and the lifetimes of the signatures created with those keys (although it is
mentioned above). I always understood the reason for having two key types is so
that one of them can be rolled more often, and have shorter signatures
lifetimes, while the other one lives longer, and is needed less often. So the
first one would not need to be as strong as the second one.

So on the one hand, neither key should be weak enough to be attacked at all. But
on the other hand, if they are equally strong, they're gonna attack the one that
has the longest lifetime and/or the longest signature lifetimes. It seems to me
that it would then make sense to roll/resign with the KSK as least as often as
you roll/resign with the ZSK (since they are equally strong).

It's probably the friday talking, but in that case, why even have a KSK at all?

Jelte

---

From: Evan Hunt <[email-masked]>
Date: Fri, 24 Apr 2009 17:47:22 +0000

> That is fine, but so is 1024 bit KSKs. The text in RFC 4641bis makes it
> clear that KSKs should be rollable in case of an emergency; the effort to
> do so is greater, but not that much greater, than rolling a ZSK.

Considering the necessity of getting new DS/DLV records into the parent/DLV
zones and/or getting public keys properly distributed to everyone who needs
them (either directly or via ITAR or other key repositories) it sure seems
to me that the effort to roll a KSK is "that much greater".  Rolling a ZSK
doesn't require coordination with anyone else.

> I prefer (b), but (a) keeps coming up in this discussion.

It's a little imprecise, but I'm inclined to think of key lifetime as an
aspect of key strength.  A 1024-bit key that rolls over every week may be
"stronger", in a sense, than a 2048-bit key that stays around for twenty
years--the second one could be broken within its lifetime, the first one
probably not.

IMHO it's reasonable to make recommendations with that tradeoff in mind; a
ZSK may be as long as a KSK, or it may be shorter if it's rolled over more
frequently.  (I think 4641bis already says something along those lines.)

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Apr 2009 14:03:03 -0400

>I prefer (b), but (a) keeps coming up in this discussion.

The reason (a) is held as conventional wisdom by some set of folks...

In the beginning we had keys.  In the early workshops we realized 
that there were two kinds of delegations where keys mattered. 
Delegations we made to ourselves and delegations made to us from 
someone else.  (In the workshops the leader was the DNS parent to all 
of the participants' child zones.)

We realized when we tried to do key rolls (because we knew that keys 
wore out) that it was much easier to change keys when it was us 
delegating to our self than when we had to run down the instructor 
(who was generally looking at a bug rooted in the specification, 
code, or configuration).

Stirring this around in the primordial soup, the ZSK and KSK was 
born.  (Eliding the rationale.)  And along the way the SEP flag was 
born.

In modern times this has translated into this issue.  When it comes 
time to design our ZSK roll, we realize all of the steps involve 
internal matters.  Running a key generation task first.  Moving the 
private key files around is the next task.  Removing the old key is 
the last step.  We can predict the time it takes to do all of the 
steps, we can do all this unannounced, when can even target all the 
normal ops to be started via cron.

When it comes to a KSK, we have to involve an external entity.  When 
it comes to planning and writing the tasks, we (at this time) have no 
idea of the interface our parent will use (if they ever do sign) and 
what the response time will be - will if be < 5 minutes or > 5 days?

As architect, I really don't care if the KSK is longer than the ZSK, 
I don't care if the KSK is stronger than the ZSK.  What matters is 
that I just have to roll the KSK much less and have it be a less 
important operation in my activities.  I can be more specific about 
ZSK life cycle, it's the KSK life cycle that has a huge unknown (the 
relationship with the parent).

As someone who has been developing DNSSEC I certainly understand (b). 
There was a time the KEY RR had a signatory field which was thought 
to be a reflection of strength - RFC 2065, section 3.3:

         Bits 12-15 are the "signatory" field.  If non-zero, they
    indicate that the key can validly sign RRs or updates of the same
    name.  If the owner name is a wildcard, then RRs or updates with any
    name which is in the wildcard's scope can be signed.  Fifteen
    different non-zero values are possible for this field and any
    differences in their meaning are reserved for definition in
    connection with DNS dynamic update or other new DNS commands.  Zone
    keys always have authority to sign any RRs in the zone regardless of
    the value of this field.  The signatory field, like all other aspects
    of the KEY RR, is only effective if the KEY RR is appropriately
    signed by a SIG RR.

We realized overtime that all keys are equal when it comes to 
strength because the validation chain caused "fate sharing."  I.e., 
if the zone above you has a 512 bit key, your 1024 and 2048 kit keys 
aren't all that "valuable" if you are optimizing for 
crypto-mathematical wizardry.  I.e., KSKs are no more special than 
ZSKs in the validation chain.

The conventional wisdom to make the KSK longer is that we just want 
to avoid frequently having to bug our parent.  It wasn't rooted in 
thinking the KSK is any more special cryptographically.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Apr 2009 16:03:24 -0400 (EDT)

> years--the second one could be broken within its lifetime, the first one

But the essential part is that once you see, say after 10 years, that the KSK
2048 bit key comes into the "feasable but impractial" scale of things due
to advacements in math or technology, that you can decided to roll it over
fairly quickly.

> frequently.  (I think 4641bis already says something along those lines.)

What I was told by my "lunching cryptographer" was that 1024bits were more
then enough even for multi year KSK's, assuming sining only, no encryption.

>From a cryptography strength point of view, more is always better,
but now you need to consider work done by you and resolvers, and space
constrictions with the DNS packet size.

I don't see a cryptographic reason for Paul Hoffman's "I'd like the keys to
be of equal size". Unless you'd argue that the KSK could easilly also be
1024bit, and that the additional 11 months of validity of the KSK is
negligable compared to the time now upto 3 years from now, to break a 1024
bit RSA key.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Apr 2009 16:09:42 -0400 (EDT)

> first one would not need to be as strong as the second one.

There is another aspect.

> It's probably the friday talking, but in that case, why even have a KSK at all?

One can be stored in a slow HSM or might be required to be "online" permanently,
while the other would only be needed once a month and can be stored offline. So
despite the equal keysize, there is not an equal trust with these keys.

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 24 Apr 2009 19:53:27 -0400

> negligable compared to the time now upto 3 years from now, to break  

What benefit is there of keeping the KSK small (e.g. 1024 bits)  
instead of just choosing the maximum that your signing software  
permits (e.g. 4096 bits, I think, with dnssec-signzone)?

EDNS0 is a prerequisite for DNSSEC, if memory serves, so it's  
presumably not TCP fallback we're worried about with larger DNSKEY  
RDATA. A 4096 bit key only represents 384 more bytes of RDATA in a  
DNSKEY resource record on the wire than a 1024 bit key, and 384 bytes  
doesn't sound (naively, no science) like it's going to break the bank.

Is the root concern the computational expense of dealing with larger  
keys in a validator? Or something else? Whatever the root concern is,  
what are the boundaries?

It seems fruitless to debate whether 1024 bits is sufficient if  
there's no real cost to just choosing (say) 4096 bits and avoiding the  
discussion.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2009 18:17:56 -0700

At 7:53 PM -0400 4/24/09, Joe Abley wrote:
>It seems fruitless to debate whether 1024 bits is sufficient if there's no real cost to just choosing (say) 4096 bits and avoiding the discussion.

Please read the text: larger keys incur a real cost to people validating.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Fri, 24 Apr 2009 21:46:15 -0400

On 24 Apr 2009, at 21:17, Paul Hoffman wrote:

>> there's no real cost to just choosing (say) 4096 bits and avoiding  
>> the discussion.
>

The text contains the following sentence: "In a standard CPU, it takes  
about four times as long to sign or verify with a 2048-bit key as it  
does with a 1024-bit key." I couldn't find any other discussion of the  
cost to validators of large key sizes.

If there is a practical limit to key size due to concerns about  
peoples' validators running out of steam, then I think it needs to be  
stated clearly. Otherwise as a zone administrator my instinct will be  
to use keys that are as large as possible, since the costs incurred by  
doing so are going to be borne by other people and all I see is  
benefit (in the form of increased comfort level and a better story for  
upper management, even if there is no practical improvement in  
security).

On the flip side, how can the "real cost" for validator-operators that  
you assert be quantified?

I have a hand in running a couple of non-validating resolvers for a  
local ISP. 35,000 customers are served by two machines running BIND  
9.5.x on FreeBSD 7.1, and the CPUs are 96% idle at peak load. That's a  
fair amount of headroom, even ignoring the fact that the ISP in  
question is in the process of replacing each machine with an ECMP/OSPF  
cluster of two machines in order to simplify ad-hoc maintenance.

I'm not arguing about the assertion that there is a limit to what  
validators can tolerate. However, it seems reasonable to ask if it's  
the kind of limit that we need to worry about, and not, the kind of  
limit that is always going to fit in that headroom as validator  
hardware gets upgraded on a typical cycle and DNSSEC deployment  
proceeds over time.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2009 19:18:51 -0700

At 9:46 PM -0400 4/24/09, Joe Abley wrote:
>The text contains the following sentence: "In a standard CPU, it takes about four times as long to sign or verify with a 2048-bit key as it does with a 1024-bit key." I couldn't find any other discussion of the cost to validators of large key sizes.

2048 is "large". :-) As I said earlier in this thread, 'openssl speed' is your friend.
                  sign    verify    sign/s verify/s
rsa 1024 bits 0.007343s 0.000322s    136.2   3107.6
rsa 2048 bits 0.042943s 0.001093s     23.3    914.8
rsa 4096 bits 0.275508s 0.003920s      3.6    255.1

At least on this box with this build of OpenSSL, the multiplier is about three times for each doubling of the key size.

>If there is a practical limit to key size due to concerns about peoples' validators running out of steam, then I think it needs to be stated clearly. Otherwise as a zone administrator my instinct will be to use keys that are as large as possible, since the costs incurred by doing so are going to be borne by other people and all I see is benefit (in the form of increased comfort level and a better story for upper management, even if there is no practical improvement in security).

That's certainly your option. Another option is to listen to cryptographers about what is possible with a reasonable amount of money and time, and stop there.

>On the flip side, how can the "real cost" for validator-operators that you assert be quantified?

Exactly.

>I have a hand in running a couple of non-validating resolvers for a local ISP. 35,000 customers are served by two machines running BIND 9.5.x on FreeBSD 7.1, and the CPUs are 96% idle at peak load. That's a fair amount of headroom, even ignoring the fact that the ISP in question is in the process of replacing each machine with an ECMP/OSPF cluster of two machines in order to simplify ad-hoc maintenance.
>
>I'm not arguing about the assertion that there is a limit to what validators can tolerate. However, it seems reasonable to ask if it's the kind of limit that we need to worry about, and not, the kind of limit that is always going to fit in that headroom as validator hardware gets upgraded on a typical cycle and DNSSEC deployment proceeds over time.

How will you know? Why not stop when enough is enough?

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Fri, 24 Apr 2009 22:25:19 -0400

On 24 Apr 2009, at 22:18, Paul Hoffman wrote:

>> peoples' validators running out of steam, then I think it needs to  
>> be stated clearly. Otherwise as a zone administrator my instinct  
>> will be to use keys that are as large as possible, since the costs  
>> incurred by doing so are going to be borne by other people and all  
>> I see is benefit (in the form of increased comfort level and a  
>> better story for upper management, even if there is no practical  
>> improvement in security).
>
> That's certainly your option. Another option is to listen to  
> cryptographers about what is possible with a reasonable amount of  
> money and time, and stop there.

My point is that given the choice between "doing what is currently  
considered safe" and "exceeding what is currently considered safe by a  
factor of four with no additional cost to you" I think many otherwise  
uninformed zone administrators are conditioned to choose the latter.

>> that you assert be quantified?

So your point is that you don't know how to quantify it?

>> 9.5.x on FreeBSD 7.1, and the CPUs are 96% idle at peak load.  
>> That's a fair amount of headroom, even ignoring the fact that the  
>> ISP in question is in the process of replacing each machine with an  
>> ECMP/OSPF cluster of two machines in order to simplify ad-hoc  
>> maintenance.
>>
>> validators can tolerate. However, it seems reasonable to ask if  
>> it's the kind of limit that we need to worry about, and not, the  
>> kind of limit that is always going to fit in that headroom as  
>> validator hardware gets upgraded on a typical cycle and DNSSEC  
>> deployment proceeds over time.
>

Because there's no incentive for a zone administrator to choose  
anything other than the largest key her tools let her create. So what  
is "enough"?

Joe

---

From: [email-masked]
Date: Sat, 25 Apr 2009 02:29:44 +0000

Yo Joe,

	many moons back, it was pointed out to me by some cryto folks that there is an
interesting relationship btwn key length and signature duration.  One could make the argument
that for persistent delegations, you might want to ensure longer length keys and possibly
longer duration signatures than you might have for a DHCP lease whos's lifetime is 20 minutes.
	e.g. a leaf assignment that lasts no longer than 20 minutes might not justify the
operational cost of a 4096bit key generation/propogation, while a well-known TLD (.JOE)
might well justify a 4096bit key.  you might say that key length should/could be inversely
proporational to the delegation placement in the namespace.

	but you knew this.

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2009 19:45:52 -0700

At 10:25 PM -0400 4/24/09, Joe Abley wrote:
>My point is that given the choice between "doing what is currently considered safe" and "exceeding what is currently considered safe by a factor of four with no additional cost to you" I think many otherwise uninformed zone administrators are conditioned to choose the latter.

...which a good reason why we give actual numbers in this draft.

I don't see where you are going with this. Do you want us to give hard numbers and not justify them so admins won't pick anything else? Or?

>So your point is that you don't know how to quantify it?

Correct. How can you know how many other zone admins waste cycles on validator boxes? How can you know how many cycles are being used on those boxes for other things?

>Because there's no incentive for a zone administrator to choose anything other than the largest key her tools let her create. So what is "enough"?

An attack that would cost hundreds of millions of dollars and take longer than your key will be valid. This was covered earlier in this thread.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Apr 2009 22:46:35 -0400 (EDT)

On Fri, 24 Apr 2009, Joe Abley wrote:

> What benefit is there of keeping the KSK small (e.g. 1024 bits) instead of

> EDNS0 is a prerequisite for DNSSEC, if memory serves, so it's presumably not 
> TCP fallback we're worried about with larger DNSKEY RDATA.

I might run into some rally strange networks with my dnssec resolver on my
laptop. At least, the chance of broken strange networks is much higher
then the chance of receiving a notice that RSA 1024 can be broken within
one year.

(I am not advocating 1024bits for the KSK, I am just answering with a possible
benefit of keeping a small KSK)

> only represents 384 more bytes of RDATA in a DNSKEY resource record on the 
> wire than a 1024 bit key, and 384 bytes doesn't sound (naively, no science) 
> like it's going to break the bank.
>
> Is the root concern the computational expense of dealing with larger keys in 
> a validator? Or something else? Whatever the root concern is, what are the 
> boundaries?
>
> It seems fruitless to debate whether 1024 bits is sufficient if there's no 
> real cost to just choosing (say) 4096 bits and avoiding the discussion.

I believe the main issue is packet size, not CPU power on the (stub) resolver.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Apr 2009 21:55:01 -0500

On Apr 24, 2009, at 9:45 PM, Paul Hoffman wrote:
> Correct. How can you know how many other zone admins waste cycles on  
> validator boxes? How can you know how many cycles are being used on  
> those boxes for other things?

Plus, forgive me for being obnoxious, when you quadruple the workload,  
how much additional energy does that burn?   (Assuming that DNSSEC  
gets widely deployed, of course, so that the multiplier is really large)

---

From: Joe Abley <[email-masked]>
Date: Sat, 25 Apr 2009 00:00:50 -0400

On 24 Apr 2009, at 22:45, Paul Hoffman wrote:

>> considered safe" and "exceeding what is currently considered safe  
>> by a factor of four with no additional cost to you" I think many  
>> otherwise uninformed zone administrators are conditioned to choose  
>> the latter.
>
> I don't see where you are going with this.

Yeah, sorry for being vague.

> Do you want us to give hard numbers and not justify them so admins  
> won't pick anything else?

The advice in the document seems fine. I wonder whether it is complete.

If there's an expectation that people will choose bigger keys because  
they can, and that there are operational reasons why this would be  
bad, it seems sensible to explain those reasons as additional  
incentive for people not to do it. I don't think the current text  
really identifies those reasons very clearly.

But really I was more concerned that it wasn't obvious what those  
operational reasons might be.

Joe

---

From: Peter Koch <[email-masked]>
Date: Mon, 27 Apr 2009 13:19:45 +0200

> in the RFC to alert people to the possibility makes sense.

in an attempt to summarize and give our editors some guidance, is it OK
to read

o the protection of the key against (unauthorized) copying should be
  weighed against the chance of detection, the remaining window of
  opportunity for the attacker and the "cost" of rolling the (compromised)
  key.

o the WG believes that the use of HSMs for DNSSEC KSKs is useful {is
  that useful as in "RECOMMENDED"?} for a certain type of zones ("high
  profile"?) to minimize the risk of an unnoticed key compromise (copy).

o HSMs for ZSKs might be less efficient (as in signatures/second) and
  effective, since the ease of automation generally preferred for this
  type makes the attacker's job easier (you might not be able to copy
  the key, but you might be able to get a valid signature on arbitrary data).

The term "HSM", though, doesn't imply any particular security level
unless some certification is provided.  If the WG would like to make
recommendations here, we should keep in mind who our target audiences are
and how to serve an international readership, especially if the to-be-BCP
should make it into or be referenced by some RFP type document.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Apr 2009 09:05:54 -0400

Speaking as the voice that questioned HSMs...

>   profile"?) to minimize the risk of an unnoticed key compromise (copy).

I would say "it's useful" not "for a certain type of zone" but in 
operations where access to the signing machine cannot be sufficiently 
controlled for one reason or another, where the likelihood that an 
unauthorized person could gain access to the private key is greater 
than the threshold of comfort.  It's not so much the kind of zone it 
is, but rather the way the zone is operated/engineered.

I.e., even though I'd question why an HSM is appropriate in some 
circumstances, I still think they can be useful in a wide range of 
operational models.

>should make it into or be referenced by some RFP type document.

Perhaps we should avoid the RFC 5513 "HSM" and just spell it out - a 
(cryptographic) hardware support module.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Joe Abley <[email-masked]>
Date: Mon, 27 Apr 2009 09:16:14 -0400

> (cryptographic) hardware support module.

Hardware Security Module is the more usual expanded form, I think?

Joe

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Apr 2009 09:30:06 -0400

>Hardware Security Module is the more usual expanded form, I think?

Wikipedia sides with you, Joe.

Toh-may-to, Toh-ma-toh. ;)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Apr 2009 07:46:07 -0700

At 9:16 AM -0400 4/27/09, Joe Abley wrote:
>>Perhaps we should avoid the RFC 5513 "HSM" and just spell it out - a (cryptographic) hardware support module.
>

It is indeed. "hardware support module" sounds like a crypto accelerator chip, which has a completely different function, one that doesn't include holding private keys.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Apr 2009 22:21:03 +0200

In your previous mail you wrote:

=> there are places where cryptography is required to be implemented
in hardware, and many business reasons or even regulations which
mandate HSMs.

=> the main function of a HSM is to provide a key store where private
keys may not and cannot be extracted (i.e., not only the operation
is not allowed but the device is protected against common up to
all known ways to extract protected values). So it is possible
to misuse a HSM, for instance to make it to sign something, but
the keys can't leak.
In conclusion when HSMs are not an excuse to forget to carefully manage
DNSSEC servers, I have nothing at all against HSMs...

Regards

[email-masked]