On Thu, 3 Apr 2014, David Conrad wrote:
We want to make security decisions that actually improve security.
Making a decision that results in people turning security off because the
(perceived at least) performance impact is too large does not improve security.
I'm happy to hear the browser v
On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan wrote:
> On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote:
> > 1) Client -> Resolver
>
> > Changing 1 is the easiest and also the part that is most in need.
>
> >From where I sit, that project appears to reduce to roughly "upgrad
Paul,
On Apr 3, 2014, at 12:38 AM, Paul Wouters wrote:
>>> Saving space and time does matter. Roughly half the operators I studied
>>> would include a backup key on-line because “they could” with the shorted
>>> length. And performance does matter - ask the web browser people.
> Because we wa
On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote:
> 1) Client -> Resolver
> Changing 1 is the easiest and also the part that is most in need.
>From where I sit, that project appears to reduce to roughly "upgrade
all the computers on Earth." It may be that we do not have a com
On Wed, Apr 2, 2014 at 7:31 PM, Andrew Sullivan wrote:
> On Wed, Apr 02, 2014 at 07:21:11PM -0400, Phillip Hallam-Baker wrote:
>
> > Which is why I have been pushing the notion that if we are going to do
> DNSE
> > then part of the DNSE solution should be to get us out of the single
> > response p
On Wed, Apr 02, 2014 at 07:21:11PM -0400, Phillip Hallam-Baker wrote:
> Which is why I have been pushing the notion that if we are going to do DNSE
> then part of the DNSE solution should be to get us out of the single
> response packet straightjacket.
I've seen what you've had to say on that, an
On Wed, Apr 2, 2014 at 11:19 AM, 🔒 Roy Arends wrote:
> On 02 Apr 2014, at 15:19, Jim Reid wrote:
>
> > There's been a lot of noise and very little signal in the recent
> discussion.
> >
> > It would be helpful if there was real data on this topic. Is an RSA key
> of N bits too "weak" or too "str
Hi Scott,
At 10:13 02-04-2014, Rose, Scott wrote:
The only DNSSEC related NIST SP's are 800-57 and 800-81-2. SP
800-57 is in 3 parts, part one is general key considerations and
part 3 covers specific uses like DNSSEC. It's showing its age though.
The US Federal policy (now) is 2048 bit RSA f
On Wed, Apr 2, 2014 at 2:40 PM, Mark Andrews 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 r
In message
, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
>
> 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
Speaking for myself:
First: Thank you Jim and Joe for seeking to increase the signal-to-noise ratio
on this thread and for explaining what the attack vector would be for lower IQ
folk like myself.
Second: I have always taken my instructions from the community. So regardless
of what I believe
Nicholas,
On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote:
>
...
> And please don't discount the psychology of the issue. If DNSSEC
> wants to be taken seriously, it needs to show it. Using short keys
> for root and the major TLDs, under the assumptions that it can't be
> crack
On Apr 2, 2014, at 11:19 AM, 🔒 Roy Arends wrote:
>
> Just a thought that occured to me. Crypto-maffia folk are looking for a
> minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk
> are looking for a maximum (i.e. at most soo many bits otherwise
> fragmentation/fallbac
All,
This is the beginning of the Working Group Last Call on Child To Parent
Synchronization in DNS.
The London update showed that this work is complete and ready to move
forward.
The document can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
http://w
Greetings,
This is the starting of the WGLC on Automating DNSSEC delegation trust
maintenance. This was briefly covered in London and these are ready for
WGLC. The current versions of this documents can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maint
On Apr 2, 2014, at 12:06 PM, S Moonesamy wrote:
>
>> What does it matter from a security perspective? DNS messages are short
>> lived. It's not like we are encrypting a novel to be kept secret for 100
>> years. With zone signing keys lasting a month, 6 months, or so, and the
>> ability to
On Wed, Apr 02, 2014 at 11:33:20AM -0400, Ted Lemon wrote:
> Bear in mind that all you _really_ have to do is get a bogus ZSK with the
> current time into the resolver, which you may be able to do with some
> clever NTP shenanigans over a relatively short timescale. But yeah,
> this isn't likely
On Apr 2, 2014, at 8:26 AM, Colm MacCárthaigh wrote:
> Cryptographic failures are often undemonstrated for decades.
This is an important point, particularly when talking about RSA keys. It is
important to note that RSA keys are *not* broken by brute force. There is some
tricky math that is us
Hi Ed,
At 06:30 02-04-2014, Edward Lewis wrote:
I found that there are two primary reasons why 1024 bits is used in
zone signing keys.
One - peer pressure. Most other operators start out with 1024
bits. I know of some cases where operators wanted to choose other
sizes but were told to "fol
On Wed, 2 Apr 2014, Nicholas Weaver wrote:
Well, its because for the most part, cryptographers do seem to understand that
DNSSEC is a bit of a joke when it comes to actually securing conventional DNS
records.
Funny, the cryptographers I talk to, like at the University of Waterloo,
have alway
On Apr 2, 2014, at 10:49 AM, Joe Abley wrote:
> This seems like an intractably difficult thing to accomplish.
Bear in mind that all you _really_ have to do is get a bogus ZSK with the
current time into the resolver, which you may be able to do with some clever
NTP shenanigans over a relatively
On Wed, Apr 2, 2014 at 11:31 AM, Christopher Morrow
wrote:
> On Wed, Apr 2, 2014 at 11:19 AM, 🔒 Roy Arends wrote:
>
>> Just a thought that occured to me. Crypto-maffia folk are looking for a
>> minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk
>> are looking for a max
On Wed, Apr 2, 2014 at 11:19 AM, 🔒 Roy Arends wrote:
> Just a thought that occured to me. Crypto-maffia folk are looking for a
> minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk
> are looking for a maximum (i.e. at most soo many bits otherwise
> fragmentation/fallba
On Wed, Apr 2, 2014 at 6:30 AM, Edward Lewis wrote:
> I found that there are two primary reasons why 1024 bits is used in zone
> signing keys.
>
> One - peer pressure. Most other operators start out with 1024 bits. I
> know of some cases where operators wanted to choose other sizes but were
> t
Joe Abley (jabley) writes:
>
>
> 1. subverting sufficient NTP responses over a long enough period to cause the
> remote resolver's clock to turn back in time (long period suggested due to
> many/most? implementations' refuse large steps in times, and hence many
> smaller steps might be require
On 02 Apr 2014, at 15:19, Jim Reid wrote:
> There's been a lot of noise and very little signal in the recent discussion.
>
> It would be helpful if there was real data on this topic. Is an RSA key of N
> bits too "weak" or too "strong"? I don't know. Is N bits "good enough"?
> Probably. Change
Colleagues,
We've noted the tone some participants in the key length discussion have taken,
and the complaints about it.
We're handling off-list, in accordance with IETF mailing list moderation
policy.
Understood that this is a frustrating topic, but less heat, more light, please.
thanks,
On 2 Apr 2014, at 10:26, Ted Lemon wrote:
> The problem with the way you've phrased this question is that there does not
> seem to be agreement amongst the parties to this discussion whether old keys
> matter. If you think they do, you need longer keys. If you think they
> don't, you need
On Apr 2, 2014, at 10:19 AM, Jim Reid wrote:
> My gut feel is large ZSKs are overkill because the signatures should be
> short-lived and the keys rotated frequently. Though the trade-offs here are
> unclear: is a 512-bit key that changes daily (say) better than a 2048-bit key
> that gets rotate
On Apr 2, 2014, at 6:44 AM, Nicholas Weaver wrote:
> The profanity is deliberate.
And so is the pushback against it. You may believe that the only way to get the
operational change you want in the root zone is to be obnoxious and repetitive;
others may believe that you are purposely hurting
There's been a lot of noise and very little signal in the recent discussion.
It would be helpful if there was real data on this topic. Is an RSA key of N
bits too "weak" or too "strong"? I don't know. Is N bits "good enough"?
Probably. Change the algorithm and/or value of N to taste.
My gut fee
On Apr 1, 2014, at 8:02 PM, Olafur Gudmundsson wrote:
>
> 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 a
On Tue, Apr 01, 2014 at 10:37:54PM -0400,
Olafur Gudmundsson 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 opinion. This is
The profanity is deliberate. The same discredited performance arguments have
come up for a decade+. It gets very frustrating to see the same ignorance,
again and again.
On Apr 2, 2014, at 6:30 AM, Edward Lewis wrote:
>> From these two main reasons (and you’ll notice nothing about cryptograph
After a break of a few months I rejoined the DNSOP WG mail list. After the very
first message I sent a complaint to the chairs over the tone and language. I
feel I should send a note about that to the open list itself.
It’s not that I have a puritan tongue. It’s that such low-brow language,
i
On Tue, 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 advant
36 matches
Mail list logo
