On Mar 27, 2014, at 10:14 AM, Matthäus Wander
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 bit: 8893
> 1536
On 27 Mar 2014, at 17:47, 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
On 27 Mar 2014, at 10:05, Nicholas Weaver wrote:
> On Mar 27, 2014, at 7:22 AM, Joe Abley wrote:
>
>> On 27 Mar 2014, at 22:56, Nicholas Weaver wrote:
>>
>>> Bits are not precious: Until a DNS reply hits the fragmentation limit of
>>> ~1500B, size-matters-not (tm, Yoda Inc).
>>>
>>> So
Nope.
ALL 1024 bit certs of every description are covered including end-entity.
On Thu, Mar 27, 2014 at 3:35 PM, Paul Wouters 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 revoke just t
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
The overall problem of using old root keys will persist (and eventually I think
DNSSEC resolvers need to refuse ZSKs for . and tlds that are less than 2048b in
length, or barring that, need to add a clock ratchet to keep old keys from
being reused).
But fixing this going forward requires a 1-l
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 revoke just those CAs once someone breaks a 1024b example, since
the browser vendors have good experience in revoking bad CAs already (queue
DigiNotar...)
On Thu, Mar 27, 2014 at 2:39 PM, Nicholas Weaver
wrote:
>
> On Mar 27, 2014, at 11:18 AM, Christopher Morrow
> wrote:
>
>> On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman wrote:
>>> Yes. If doing it for the DNS root key is too politically challenging, maybe
>>> do it for one of the 1024-bit tru
On Mar 27, 2014, at 11:18 AM, Christopher Morrow
wrote:
> On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman 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 politi
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman 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?
___
DN
-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 (collecte
On Thu, Mar 27, 2014 at 03:17:04PM +,
Rose, Scott 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 KSK and ZSK (not bec
On Mar 27, 2014, at 10:22 AM, Joe Abley wrote:
>
> On 27 Mar 2014, at 22:56, Nicholas Weaver 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 ev
On Mar 27, 2014, at 7:22 AM, Joe Abley wrote:
>
> On 27 Mar 2014, at 22:56, Nicholas Weaver 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 ev
On Thu, Mar 27, 2014 at 11:05 AM, Nicholas Weaver 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 seriously.
>
>
I think I know h
On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman wrote:
> On Mar 27, 2014, at 6:56 AM, Nicholas Weaver
> 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 pas
The NIST Guidance is from 2009. It is long since obsolete.
This is one of the reasons why we need to take advice on crypto algorithms
in house and make them IETF wide. Which is why I was asked to write this:
https://datatracker.ietf.org/doc/draft-hallambaker-consensuscrypto/
Having DNSSEC use 1
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver 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 their estimate.
> Do you
On 27 Mar 2014, at 22:56, Nicholas Weaver 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 the actual signing?
Th
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver 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 sieving to factor the
> roo
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, an
All,
I've gone through a large portion of the minutes of both sessions from
London, and have cleaned up a few things.
I have put a first iteration in the meeting tracker:
http://www.ietf.org/proceedings/89/minutes/minutes-89-dnsop
If people themselves being misqouted please let me know. I g
22 matches
Mail list logo
