On Tue, 21 Apr 2009, Shane Kerr wrote:
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.
You could use something like Shamir's se
On Tue, 21 Apr 2009, Paul Hoffman wrote:
'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 slowe
At 10:07 PM +0200 4/21/09, Shane Kerr wrote:
>Paul Hoffman wrote:
>>
>> ...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 temporar
At 14:09 -0400 4/21/09, Andrew Sullivan wrote:
Anyway, I completely agree that this is a cost-benefit analysis that
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-bene
At 13:50 -0400 4/21/09, Paul Wouters wrote:
No, they just connect to the bogus largebank.com and steal more then
your gross
turnover
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
Paul,
Paul Hoffman wrote:
>
> ...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, o
Edward Lewis wrote:
> In a way, I figure - "if you can read my private key, I have larger
> issues to deal with."
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) wa
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 nee
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
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 q
At 1:09 PM -0400 4/21/09, Edward Lewis wrote:
>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.
>
At 12:00 -0400 4/21/09, Andrew Sullivan wrote:
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: th
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,
At 1:03 PM +0200 4/21/09, Shane Kerr wrote:
>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
Stephane,
Stephane Bortzmeyer wrote:
>
> 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 thin
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
At 17:32 +0200 4/21/09, Stephane Bortzmeyer wrote:
On Tue, Apr 21, 2009 at 11:25:59AM -0400,
Edward Lewis 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
On Tue, Apr 21, 2009 at 11:25:59AM -0400,
Edward Lewis 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
At 17:03 +0200 4/21/09, Florian Weimer wrote:
* Edward Lewis:
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 k
* Edward Lewis:
> 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
> fortifi
At 13:03 +0200 4/21/09, Shane Kerr wrote:
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.
It might be more useful to re
All,
internet-dra...@ietf.org 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 throug
22 matches
Mail list logo
