On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh 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 get a
> valid
On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt 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 specific, so
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 analysi
On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson wrote:
Pardon my language, but you are repeating the same bogus performance arguments
that have hurt crypto for years. Having heard the same thing, over and over
and over again, over the better part of a decade and change, it really does get
to
In message <20140402025854.gb90...@mx1.yitter.info>, Andrew Sullivan writes:
> 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 t
On Tue, 1 Apr 2014, Olafur Gudmundsson wrote:
Over the years I have been saying use keys that are appropriate, thus for
someone like Paypal it makes sense to have strong keys,
but for my private domain does it matter what key size I use?
That depends. How much money is in your o...@ogud.com p
On Tuesday, April 1, 2014, Olafur Gudmundsson 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 the overall
On Apr 1, 2014, at 10:48 PM, Paul Hoffman wrote:
> On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson 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 newer
> curves do have adva
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 r
In message
, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
>
> On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews 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
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 Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson 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 newer
curves do have advantages, but they are also newer.
--Paul Hoffman
__
On Apr 1, 2014, at 11:15 AM, Colm MacCárthaigh wrote:
>
> On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson 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
> ve
On Apr 1, 2014, at 9:05 AM, Nicholas Weaver wrote:
>
> On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson 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
>> verific
On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews 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 answers.
>
In message
,
=?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 wrote:
> >
> > As I have said many times. There is a myth that recursive servers
> > do not need to valid
On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews 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 bogus an
In message
, Phillip Hallam-Baker writes:
>
> On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
> wrote:
>
> >
> > On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson wrote:
> > >
> > > Doing these big jumps is the wrong thing to do, increasing the key size
> > increases three things:
> > > tim
On Tue, Apr 1, 2014 at 6:39 AM, Phillip Hallam-Baker wrote:
> On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver > 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 CPU core-day
>> to validate every D
On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson 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 than
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 Apr 1, 2014, at 6:39 AM, 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 Resolv
On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver
wrote:
>
> On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson 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
> > ver
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson 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 than bi
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson 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 than bits
On Mar 27, 2014, at 6:54 PM, Bill Woodcock wrote:
>
> 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: 6982
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 plaus
27 matches
Mail list logo
