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
Ed,
On Apr 23, 2009, at 9:52 AM, Edward Lewis wrote:
I figure stub resolvers were needed when cpu/bandwidth/memory were
a bit
more expensive than now. It seems a shame to constrain our
architecture
to the '80s...
OTOH, for the one of the same reasons DHCP is so popular, that is
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
14 matches
Mail list logo
