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 Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:
DNSSEC is a mitigation against spoofed responses, man-in-the-middle
interception-and-rewriting and cache compromises. These threats are
endpoint and path specific, so it's entirely possible that one of your
resolvers (or its
On Wed, Apr 02, 2014 at 09:39:43AM +1100, Mark Andrews wrote:
Always set CD=1 is also bad advice. Stub resolvers need to send
both CD=1 and CD=0 queries and should default to CD=0. CD=1 should
be left to the case where they get a SERVFAIL result to the CD=0
to handle the case where the
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
On Wed, Apr 02, 2014 at 02:23:50PM +1100, Mark Andrews wrote:
And I pointed out before RFC 6840 was published that the appendix
was incomplete in its analysis.
For whatever it's worth, my recollection is that, among other things,
you offered the sort of calm, reasoned, fully-explained analysis
On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt e...@isc.org wrote:
On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:
DNSSEC is a mitigation against spoofed responses, man-in-the-middle
interception-and-rewriting and cache compromises. These threats are
endpoint and path
On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh c...@allcosts.net wrote:
I don't think this makes much sense for a coherent resolver. If I were
writing a resolver, the behaviour would instead be; try really hard to find
a valid response, exhaust every reasonable possibility. If it can't
21 matches
Mail list logo
