On 24 Apr 2009, at 22:45, Paul Hoffman wrote:
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
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
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 networ
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 condi
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 possibl
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.
>>
>>Ple
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 t
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 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
On Fri, 24 Apr 2009, Jelte Jansen wrote:
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 ca
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 I
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
> 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
zone
-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
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
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 todaywe'll see
So interestingly, the
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
> equall
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 att
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 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 o
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:
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
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
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 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
27 matches
Mail list logo
