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 through
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
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
On Tue, Apr 21, 2009 at 11:25:59AM -0400,
Edward Lewis ed.le...@neustar.biz 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
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 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:
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
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.
Paul,
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
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, 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
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) was
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, or
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
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 temporarily
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
16 matches
Mail list logo
