In your previous mail you wrote:
The verification performance is bad, P256 takes 24x times longer to verify a
signature than 2048 bit RSA key.
= I got a different figure (6x) for my ECC paper, and:
- it was published the 3 may 2013 so one can expect ECC performance
has been improved
On Tue, Apr 1, 2014 at 10:48 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson o...@ogud.com wrote:
Why not go to a good ECC instead ? (not sure which one, but not P256 or
P384)
Why not P256 or P384? They are the most-studied curves. Some of the
On Tue, Apr 01, 2014 at 10:37:54PM -0400,
Olafur Gudmundsson o...@ogud.com wrote
a message of 158 lines which said:
Furthermore using larger keys than your parents is non-sensical as
that moves the cheap point of key cracking attack.
Mostly true, but still too strong a statement, in my
On Apr 1, 2014, at 8:02 PM, Olafur Gudmundsson o...@ogud.com wrote:
On Apr 1, 2014, at 10:48 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson o...@ogud.com wrote:
Why not go to a good ECC instead ? (not sure which one, but not P256 or
P384)
At 15:47 27-03-2014, Joe Abley wrote:
There was a plan underway to roll the KSK. I was at ICANN briefly
when that started (I spoke publicly, albeit briefly about it in the
dnsop meeting in Berlin). I'm no longer at ICANN and hence no longer
have anything authoritative to say, but it seems
On Mar 27, 2014, at 6:54 PM, Bill Woodcock wo...@pch.net wrote:
On Mar 27, 2014, at 10:14 AM, Matthäus Wander matthaeus.wan...@uni-due.de
wrote:
Here's a small statistic about RSA key lengths of 741,552 signed
second-level domains (collected on 2014-01-27, counting KSK and ZSKs):
1024
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is the wrong thing to do, increasing the key size
increases three things:
time to generate signatures
bits on the wire
verification time.
I care more about verification time
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is the wrong thing to do, increasing the key size
increases three things:
time to generate signatures
bits on the wire
verification time.
I care more about verification time
On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
nwea...@icsi.berkeley.eduwrote:
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is the wrong thing to do, increasing the key size
increases three things:
time to generate signatures
On Apr 1, 2014, at 6:39 AM, Phillip Hallam-Baker hal...@gmail.com wrote:
Yes, I agree, but you are proposing a different DNSSEC model to the one they
believe in.
The DNS world has put all their eggs into the DNSSEC from Authoritative to
Stub client model. They only view the
On 04/01/2014 03:39 PM, Phillip Hallam-Baker wrote:
Yes, I agree, but you are proposing a different DNSSEC model to the one
they believe in.
The DNS world has put all their eggs into the DNSSEC from Authoritative
to Stub client model. They only view the Authoritative to Resolver as a
On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is the wrong thing to do, increasing the key size
increases three things:
time to generate signatures
bits on the wire
verification time.
I care more about verification
On Tue, Apr 1, 2014 at 6:39 AM, Phillip Hallam-Baker hal...@gmail.comwrote:
On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver nwea...@icsi.berkeley.edu
wrote:
Lets assume a typical day of 1 billion external lookups for a major ISP
centralized resolver, and that all are verified. Thats less 1
In message CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=vvrhipdk7l1zm-p0qrp8...@mail.gmail.com
, Phillip Hallam-Baker writes:
On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
nwea...@icsi.berkeley.eduwrote:
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is
On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews ma...@isc.org wrote:
As I have said many times. There is a myth that recursive servers
do not need to validate answers. Recursive servers will always
need to validate answers. Stub resolvers can't recover from recursive
servers that pass through
In message
CAAF6GDe=39bmvdotox+9coah7r06erm-juk19zwpeuvkxep...@mail.gmail.com,
=?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writ
es:
--089e011825440f264b04f604135f
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews ma...@isc.org wrote:
As I have said many
On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews ma...@isc.org wrote:
This too is going too far; of course they can, they can ask another
recursive resolver.
Which also passes through bogus answers. I will repeat stub resolvers
can't recover from recursive servers that pass through bogus
On Apr 1, 2014, at 9:05 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote:
Doing these big jumps is the wrong thing to do, increasing the key size
increases three things:
time to generate signatures
bits
On Apr 1, 2014, at 10:48 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson o...@ogud.com wrote:
Why not go to a good ECC instead ? (not sure which one, but not P256 or
P384)
Why not P256 or P384? They are the most-studied curves. Some of the
On Tuesday, April 1, 2014, Olafur Gudmundsson o...@ogud.com wrote:
you are assuming one validation per question ?
what if the resolver needs to to 10? that is 1.8ms,
I'm not :) as I wrote - if the resolver validates after it has recursed,
only the final end of the line validation increases
Paul Wouters p...@nohats.ca wrote:
On Thu, 27 Mar 2014, Nicholas Weaver wrote:
For an attacker, the root ZSK is not 1 month validity, since an attacker
who's in a position to take advantage of such a ZSK compromise is going to
be faking all of DNS for the target, and can therefore just as
On Fri, Mar 28, 2014 at 9:01 AM, Tony Finch d...@dotat.at wrote:
Paul Wouters p...@nohats.ca wrote:
On Thu, 27 Mar 2014, Nicholas Weaver wrote:
For an attacker, the root ZSK is not 1 month validity, since an
attacker
who's in a position to take advantage of such a ZSK compromise is
On Fri, Mar 28, 2014 at 09:06:17AM -0400, Phillip Hallam-Baker wrote:
Code is only vulnerable if it trusts 1024bit RSA. Code should not trust
1024bit RSA.
Therefore ICANN needs to sign the root zone with 2048 before we consider it
signed. End of story.
I think the point was that there was a
Phillip Hallam-Baker hal...@gmail.com wrote:
On Fri, Mar 28, 2014 at 9:01 AM, Tony Finch d...@dotat.at wrote:
I have a rough plan for how to avoid the insecure time replay vulnerability:
http://www.ietf.org/mail-archive/web/dnsop/current/msg11245.html
Why is this needed?
Some devices
On 28 Mar 2014, at 9:06, Phillip Hallam-Baker hal...@gmail.com wrote:
Therefore ICANN needs to sign the root zone with 2048 before we consider it
signed. End of story.
Small point of clarity: the only key that ICANN maintains is the 2048 bit KSK,
and the only signatures ICANN makes with it
On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley jab...@hopcount.ca wrote:
On 28 Mar 2014, at 9:06, Phillip Hallam-Baker hal...@gmail.com wrote:
Therefore ICANN needs to sign the root zone with 2048 before we consider
it signed. End of story.
Small point of clarity: the only key that ICANN
On 03/27/14 13:56, Nicholas Weaver wrote:
So why the hell do the real operators of DNSSEC that matters, notably com and
., use 1024b RSA keys?
And don't give me that key-roll BS: Give me an out of date key for . and a MitM
position, and I can basically create a false world for many
On Fri, Mar 28, 2014 at 11:28 AM, Thierry Moreau
thierry.mor...@connotech.com wrote:
On 03/27/14 13:56, Nicholas Weaver wrote:
So why the hell do the real operators of DNSSEC that matters, notably com
and ., use 1024b RSA keys?
And don't give me that key-roll BS: Give me an out of date
On 28 Mar 2014, at 10:26, Phillip Hallam-Baker hal...@gmail.com wrote:
VeriSign is acting on ICANN's instructions.
I think actually that Verisign is acting on NTIA's instructions under the
cooperative agreement. But my experience while I was there was that the three
organisations work in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Bill Woodcock [2014-03-27 23:54]:
On Mar 27, 2014, at 10:14 AM, Matthäus Wander
matthaeus.wan...@uni-due.de wrote:
Here's a small statistic about RSA key lengths of 741,552 signed
second-level domains (collected on 2014-01-27, counting KSK
On Fri, Mar 28, 2014 at 2:29 PM, Joe Abley jab...@hopcount.ca wrote:
On 28 Mar 2014, at 10:26, Phillip Hallam-Baker hal...@gmail.com wrote:
VeriSign is acting on ICANN's instructions.
I think actually that Verisign is acting on NTIA's instructions under the
cooperative agreement. But my
Bits are not precious: Until a DNS reply hits the fragmentation limit of
~1500B, size-matters-not (tm, Yoda Inc).
So why are both root and com and org and, well, just about everyone else using
1024b keys for the actual signing?
The biggest blobs of typical DNSSEC data are NSEC3 responses,
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
And, frankly speaking, a 3500 node cluster for a day is $75K thanks to EC2.
Do you really want someone like me to try to get an EC2 academic grant for
the cluster and a big slashdot/boingboing crowd for the
On 27 Mar 2014, at 22:56, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Bits are not precious: Until a DNS reply hits the fragmentation limit of
~1500B, size-matters-not (tm, Yoda Inc).
So why are both root and com and org and, well, just about everyone else
using 1024b keys for
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
and 1024B is estimated at only a thousand times harder.
Does that estimate include a prediction that the method to factor RSA will
improve significantly as it has in the past? The authors were unclear on that
in
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.orgwrote:
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver nwea...@icsi.berkeley.edu
wrote:
and 1024B is estimated at only a thousand times harder.
Does that estimate include a prediction that the method to factor RSA will
On Thu, Mar 27, 2014 at 11:05 AM, Nicholas Weaver nwea...@icsi.berkeley.edu
wrote:
Frankly speaking, since the root uses NSEC rather than NSEC3, IMO it
should be 4096b for both the KSK and ZSK. But I'd be happy with 2048b.
Using 1024b is a recipe to ensure that DNSSEC is not taken
On Mar 27, 2014, at 7:22 AM, Joe Abley jab...@hopcount.ca wrote:
On 27 Mar 2014, at 22:56, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Bits are not precious: Until a DNS reply hits the fragmentation limit of
~1500B, size-matters-not (tm, Yoda Inc).
So why are both root and com
On Mar 27, 2014, at 10:22 AM, Joe Abley jab...@hopcount.ca wrote:
On 27 Mar 2014, at 22:56, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Bits are not precious: Until a DNS reply hits the fragmentation limit of
~1500B, size-matters-not (tm, Yoda Inc).
So why are both root and com
On Thu, Mar 27, 2014 at 03:17:04PM +,
Rose, Scott scott.r...@nist.gov wrote
a message of 45 lines which said:
It is likely safe enough now to increase to 2048 for both KSK and
ZSK. Zones are doing this now and haven't seen any horror stories.
If you want to test, rd.nic.fr has large
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Nicholas Weaver [2014-03-27 14:56]:
So why are both root and com and org and, well, just about
everyone else using 1024b keys for the actual signing?
Here's a small statistic about RSA key lengths of 741,552 signed
second-level domains (collected
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
Yes. If doing it for the DNS root key is too politically challenging, maybe
do it for one of the 1024-bit trust anchors in the browser root pile.
why would this be politically sensitive?
On Mar 27, 2014, at 11:18 AM, Christopher Morrow christopher.mor...@gmail.com
wrote:
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
Yes. If doing it for the DNS root key is too politically challenging, maybe
do it for one of the 1024-bit trust anchors in the
On Thu, Mar 27, 2014 at 2:39 PM, Nicholas Weaver
nwea...@icsi.berkeley.edu wrote:
On Mar 27, 2014, at 11:18 AM, Christopher Morrow
christopher.mor...@gmail.com wrote:
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
Yes. If doing it for the DNS root key is too
On Thu, 27 Mar 2014, Nicholas Weaver wrote:
1 month validity.
I said don't give me that key roll crap for a reason.
A bad reason.
For an attacker, the root ZSK is not 1 month validity, since an attacker who's
in a position to take advantage of such a ZSK compromise is going to be faking
Nope.
ALL 1024 bit certs of every description are covered including end-entity.
On Thu, Mar 27, 2014 at 3:35 PM, Paul Wouters p...@nohats.ca wrote:
On Thu, 27 Mar 2014, Nicholas Weaver wrote:
Because the browsers have already decided killing of 1024b CAs is a good
idea, and they could
On 27 Mar 2014, at 10:05, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
On Mar 27, 2014, at 7:22 AM, Joe Abley jab...@hopcount.ca wrote:
On 27 Mar 2014, at 22:56, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Bits are not precious: Until a DNS reply hits the fragmentation limit of
On 27 Mar 2014, at 17:47, Joe Abley jab...@hopcount.ca wrote:
There was a plan underway to roll the KSK. I was at ICANN briefly when that
started (I spoke publicly, albeit briefly about it in the dnsop meeting in
Berlin). I'm no longer at ICANN and hence no longer have anything
On Mar 27, 2014, at 10:14 AM, Matthäus Wander matthaeus.wan...@uni-due.de
wrote:
Here's a small statistic about RSA key lengths of 741,552 signed
second-level domains (collected on 2014-01-27, counting KSK and ZSKs):
1024 bit: 1298238
2048 bit: 698232
1280 bit: 28441
4096 bit: 25326
512
49 matches
Mail list logo
