Thanks, Paul.
At 11:32 AM -0400 4/24/09, Paul Wouters wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Hoffman wrote:
At 11:32 AM -0400 4/24/09, Paul Wouters wrote:
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
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
At 9:42 -0700 4/24/09, Paul Hoffman wrote:
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.
The reason (a) is held
On Fri, 24 Apr 2009, Evan Hunt wrote:
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.
It's a little imprecise, but
On 24 Apr 2009, at 16:03, Paul Wouters wrote:
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
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
On 24 Apr 2009, at 21:17, Paul Hoffman wrote:
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
At 9:46 PM -0400 4/24/09, Joe Abley wrote:
On 24 Apr 2009, at 21:17, Paul Hoffman wrote:
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
On 24 Apr 2009, at 22:18, Paul Hoffman wrote:
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
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
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
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
Paul Hoffman wrote:
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
On Apr 22 2009, Shane Kerr wrote:
Paul Hoffman wrote:
At 10:07 PM +0200 4/21/09, Shane Kerr wrote:
[...]
The same RSA-cracker that our evil-doers dropped $10 million on to hack
web SSL will work nicely for RSA DNSSEC, thanks!
You're welcome. :-) Of course it will. It will also work on all
At 12:24 PM +0200 4/22/09, Shane Kerr wrote:
You seem to think that because there are higher-value targets nobody
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
On Wed, 22 Apr 2009, Shane Kerr wrote:
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.
Is this for ZSK or KSK? Because if you pick equal sizes, then both would be
equally vulnerable to the same brute force
Paul,
Paul Wouters wrote:
On Wed, 22 Apr 2009, Shane Kerr wrote:
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.
Is this for ZSK or KSK? Because if you pick equal sizes, then both would be
equally
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,
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 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
24 matches
Mail list logo
