> > > > - The parent is already trusted with DNSSEC tools, since the parent is
> > > > signing the parent's zone (including the DS record!)
> > >
> > > assuming facts not in evidence. there is active discussion
> > > about having unsigned zones w/ DS records included.
> >
> > Well you
On Fri, Aug 29, 2008 at 10:23:53AM +1000, Mark Andrews wrote:
>
> > > - The parent is already trusted with DNSSEC tools, since the parent is
> > > signing the parent's zone (including the DS record!)
> >
> > assuming facts not in evidence. there is active discussion
> > about having uns
> > - The parent is already trusted with DNSSEC tools, since the parent is
> > signing the parent's zone (including the DS record!)
>
> assuming facts not in evidence. there is active discussion
> about having unsigned zones w/ DS records included.
Well you are not talking
> On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
> >
> > The DS may be provided by the operator of the subordinate zone, or built
> > by the parent operator,
> > most likely the latter.
>
>
> thats an interesting premise.
> why do you think this will be the case?
> On Thu, 28 Aug 2008, Brian Dickson wrote:
>
> >>(I would posit that the folks generating the DNSKEY will also
> >>want to generate the DS hash on their known, trusted signing tools
> >>instead of trusting the parent w/ the DNSKEY materials)
> >
> > Well, here's why:
> >
> > - The DS
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
>
> The DS may be provided by the operator of the subordinate zone, or built
> by the parent operator,
> most likely the latter.
thats an interesting premise.
why do you think this will be the case?
On Thu, Aug 28, 2008 at 12:56:09AM -0400, Brian Dickson wrote:
> [EMAIL PROTECTED] wrote:
> >On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
> >
> >>The DS may be provided by the operator of the subordinate zone, or built
> >>by the parent operator,
> >>most likely the latter.
> >
On Thu, 28 Aug 2008, Brian Dickson wrote:
>> (I would posit that the folks generating the DNSKEY will also
>> want to generate the DS hash on their known, trusted signing tools
>> instead of trusting the parent w/ the DNSKEY materials)
>
> Well, here's why:
>
> - The DS is a determi
On Wed, Aug 27, 2008 at 06:54:53PM -0400, Dean Anderson wrote:
> I suggest you review the past emails and the RFC's to find out what is
> meant by a 'non-verifying DNSSEC cache'.
I have a passing familiarity with the RFCs, and the phrase
"non-verifying DNSSEC cache", and even "non-verifying", appe
[EMAIL PROTECTED] wrote:
> On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
>
>> The DS may be provided by the operator of the subordinate zone, or built
>> by the parent operator,
>> most likely the latter.
>>
>
>
> thats an interesting premise.
> why do you th
Dean Anderson wrote:
> On Sun, 24 Aug 2008, Brian Dickson wrote:
>
>
>> Dean Anderson wrote:
>>
>>> On Sun, 24 Aug 2008, Dean Anderson wrote:
>>>
>>>
>>>
Ok. But when you resign using arbitrary data controlled by the
attacker, the private key can be obtained. [There is
I suggest you review the past emails and the RFC's to find out what is
meant by a 'non-verifying DNSSEC cache'.
A DNSSEC-aware cache need not verify the responses it caches. It can
leave that task to the stub-resolver. By having the stub resolvers
perform the crypto checks, the crypto computation
On Tue, Aug 26, 2008 at 05:25:44PM -0400, Dean Anderson wrote:
> An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty
Wait a minute. You're proposing to show that "a DNSSEC cache" that
doesn't actually do DNSSEC (whatever that would mean) can be poisoned?
I'm not sure I see th
> Large UDP packets (think EDNSO DNSSEC as a good example of large UDP
> packets almost certain to be fragmented) suffer the same problem, as
> they can be fragmented by PMTU discovery. The server (operating system)
> has to maintain UDP state for PMTUD to work. If the ICMP fragmentation
> needed
On Tue, 26 Aug 2008, Andrew Sullivan wrote:
> On Tue, Aug 26, 2008 at 02:44:08PM -0400, Dean Anderson wrote:
> > I don't think I can give the exact correct mathematics without using a
> > book--and I don't have my crypto library right now--so I'll try to
> > armwave a bit:
>
> If you're claiming
Moin!
On Aug 26, 2008, at 21:02 , Dean Anderson wrote:
> Large UDP packets (think EDNSO DNSSEC as a good example of large UDP
> packets almost certain to be fragmented) suffer the same problem, as
> they can be fragmented by PMTU discovery. The server (operating
> system)
> has to maintain UDP s
On Tue, Aug 26, 2008 at 02:44:08PM -0400, Dean Anderson wrote:
> I don't think I can give the exact correct mathematics without using a
> book--and I don't have my crypto library right now--so I'll try to
> armwave a bit:
If you're claiming that, after 10 years and review unto death, people
with s
On Mon, 25 Aug 2008, Ralf Weber wrote:
> > It should be noted that unicast TCP is unstable if unicast routing
> > is unstable.
> Yes, but TCP usually adapts to the problem while anycast can't, as it
> may reach another target.
Large UDP packets (think EDNSO DNSSEC as a good example of large U
On Sun, 24 Aug 2008, Brian Dickson wrote:
> Dean Anderson wrote:
> > On Sun, 24 Aug 2008, Dean Anderson wrote:
> >
> >
> >> Ok. But when you resign using arbitrary data controlled by the
> >> attacker, the private key can be obtained. [There is a crypto attack on
> >> rekeying] OOPS!!. Rekeyi
Moin!
On Aug 26, 2008, at 02:15 , Masataka Ohta wrote:
> Could you elaborate on how fast converging routing protocols can
> be a problem?
Well I believe it was in our case as we did observe some strange
behaviour when starting to test with anycast DNS.
> Anycast TCP fails only when route change
Ralf Weber wrote:
>> It should be noted that unicast TCP is unstable if unicast routing
>> is unstable.
>
> Yes, but TCP usually adapts to the problem while anycast can't, as it
> may reach another target.
That unicast TCP fails in unusual cases means we, anyway, need
retry mechanisms, which h
Moin!
On Aug 25, 2008, at 14:56 , Masataka Ohta wrote:
> As the, seemingly, only expert on anycast in the world, anycast
> is stable as long as unicast routing is stable.
While that is true, there are situations where unicast reachabilty is
working but anycast reachabilty is not.
> It should be
Dean Anderson wrote:
> I recently read David Blacka's blog entry on Anycast, where Blacka
> asserted that Anycast had to be proven UNstable before anyone should
> consider stability questions. Blacka suggests that non-root operators
> had no experience or data to prove these things unstable--which
Brian Dickson wrote:
>>>Ok. But when you resign using arbitrary data controlled by the
>>>attacker, the private key can be obtained. [There is a crypto attack on
>>>rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net,
>>>etc. I guess you didn't know that.
>>Correction: The a
Dean Anderson wrote:
> On Sun, 24 Aug 2008, Dean Anderson wrote:
>
>
>> Ok. But when you resign using arbitrary data controlled by the
>> attacker, the private key can be obtained. [There is a crypto attack on
>> rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net,
>> etc.
On Sun, 24 Aug 2008, Dean Anderson wrote:
>
> > It is well understood that you are vulnerable to a replay attack while
> > the old RRSIGs are still valid. Which argues for short signature
> > durations, not rekeying.
>
> Ok. But when you resign using arbitrary data controlled by the
> atta
On Fri, 22 Aug 2008, Blacka, David wrote:
> If you had actually followed any of the discussions about DNSSEC over
> that last 13 years, you would know that this is false. Thinking about
> how it could break is what the vast majority of work on this topic has
> been about.
I have paid attention t
On Fri, 22 Aug 2008, Blacka, David wrote:
> >So one can use poison on a validating DNSSEC resolver to achieve false
> >resolution for any "new" unsigned zone. Put another way, the bad guy
> >can create new delegations under opt-out NSEC3 records.
>
> This fact is specifically mentioned in the Se
On Aug 22, 2008, at 6:27 PM, Dean Anderson wrote:
I didn't make fun of anyone. The lack of critical analysis is no
laughing matter.
None of the promoters seems to ever make an effort to consider how
things might break. There is far too much cheerleading and far too
little of how it could brea
On Fri, 22 Aug 2008, Ted Lemon wrote:
> On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote:
> > Sigh. Above is precisely the sort of non-critical analysis that causes
> > these things to have so many problems.
>
> Instead of making fun of other peoples' lack of critical thinking, you
> might want
On Fri, 22 Aug 2008, Matt Larson wrote:
> Dean,
>
> On Fri, 22 Aug 2008, Dean Anderson wrote:
> > It is manadatory in the _proper_ response. Of course, the _forged_
> > response can have anything the bad guy wants. If the bad guy decides
> > not to follow 4035 (gasp! we never thought the bad gu
On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote:
Sigh. Above is precisely the sort of non-critical analysis that causes
these things to have so many problems.
Instead of making fun of other peoples' lack of critical thinking, you
might want to take responsibility for your own thinking and le
On Thu, 21 Aug 2008, Frederico A C Neves wrote:
> On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote:
> > On Tue, 19 Aug 2008, Ted Lemon wrote:
> >
> > > On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> > > > A verifying
> > > > DNSSEC cache can be poised with bad glue records using
On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote:
> On Tue, 19 Aug 2008, Ted Lemon wrote:
>
> > On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> > > A verifying
> > > DNSSEC cache can be poised with bad glue records using the poisoning
> > > attack, with only a slight change to the
On Tue, 19 Aug 2008, Ted Lemon wrote:
> On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> > A verifying
> > DNSSEC cache can be poised with bad glue records using the poisoning
> > attack, with only a slight change to the Kaminsky software.
>
> Do you mean that it can be convinced that an answe
In your previous mail you wrote:
If a caching server is required to perform public key computation to
verify RRs before caching, it can't support much clients...
=> the common assumption that public key computation is slow or
expensive is *wrong*. According to 'openssl speed rsa', My old
2
At 10:30 AM -0700 8/20/08, David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
DNSSEC will st
> > no hop-by-hop solution can address the problem of a MiTM who can see
> > and/or alter your queries and responses.
>
> If you have a malicious man in the middle, he will do bad things to you.
>
> DNSSEC will not stop that.
please explain how i can get undetectably bad data in a dnssec environ
David,
On Aug 20, 2008, at 10:30 AM, David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to
you.
Yep. Question is, how many o
David Ulevitch wrote:
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
Too many pronouns...
DNSSEC provides the
Paul Vixie wrote:
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
___
DNSOP mailing li
On Tue, Aug 19, 2008 at 11:15:12PM -0400, Dean Anderson wrote:
> I don't know if anyone noticed, but in fact, according to RFC4035 the
> delegation records and the glue records are not signed. A verifying
> DNSSEC cache can be poised with bad glue records using the poisoning
> attack, with only a
Paul Vixie wrote:
> that depends on the problem statement, really. if the problem statement is
> "how can we secure hop-by-hop" then there are other solutions on the table
> right now besides DNSSEC.
Wrong.
PKI, including DNSSEC, does require hop-by-hop security between CAs,
which is no differ
[EMAIL PROTECTED] (Paul Vixie) writes:
> my chosen problem statement is "how can we secure end-to-end" because i am
> worried about corruption inside servers not just between them, and i want
> to defend against provider-in-the-middle attacks (including several that
> opendns currently monetizes.)
[EMAIL PROTECTED] (David Ulevitch) writes:
> ... -- My goal is not to derail DNSSEC. It does that on its own. My
> goal is to make sure people don't buy into the kool-aid being poured
> that DNSSEC is the only solution. It isn't.
that depends on the problem statement, really. if the problem
Dean Anderson wrote:
>>A property of Kaminsky's attack that it is effective against a single
>>target is useful, here.
> I don't know if anyone noticed, but in fact, according to RFC4035 the
> delegation records and the glue records are not signed.
Really? (I am not interested in reading RFC4035
2008/8/19 kevin graham <[EMAIL PROTECTED]>:
>
> On Tue, 19 Aug 2008, David Conrad wrote:
>
>> On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
>>>
>>> So what? NAT at airport must be, unlike NATs in enterprises,
>>> consumer friendly. Unlike highe end NAT, low end NAT won't
>>> bother to interfere
On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
A verifying
DNSSEC cache can be poised with bad glue records using the poisoning
attack, with only a slight change to the Kaminsky software.
Do you mean that it can be convinced that an answer is valid when it
is not?
___
The claims that verifying DNSSEC caches can't be poisoned isn't true
after all.
On Tue, 19 Aug 2008, Masataka Ohta wrote:
> A property of Kaminsky's attack that it is effective against a single
> target is useful, here.
I don't know if anyone noticed, but in fact, according to RFC4035 the
deleg
On Tue, 19 Aug 2008, David Ulevitch wrote:
Sort of. It means I have to start another company that will charge slightly
less egregious fees than the rest of you plan on doing to do DNSSEC
management for companies the same way Thawte and Verisign did for SSL certs.
Except now, there are no bro
On Tue, 19 Aug 2008, David Ulevitch wrote:
Nonetheless, I'll share some data. I've yet to have a single person, who was
not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS.
Well duh. For once, anyone who is asking you gets qualified as "fan boy", so
your
statement is self-fu
On Tue, 19 Aug 2008, David Conrad wrote:
On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
Right. Because low-end consumer gear is always so much
David,
On Aug 19, 2008, at 10:27 AM, David Ulevitch wrote:
Do you want to fund my costs of supporting (and encouraging my
clients to use) DNSSEC?
I don't use your service. If your customers feel there is value in
what DNSSEC can provide, they'll presumably pay you for DNSSEC
functionality
Ted Lemon wrote:
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
I've yet to be shown how DNSSEC is any of those things. D-H key
exchanges, DTLS, DNS PING, all sound far more appealing.
The answer to that question has to take into account what benefit
accrues to you from preventing DNSSEC
David Conrad wrote:
Do you want to fund my costs of supporting (and encouraging my clients
to use) DNSSEC?
I don't use your service. If your customers feel there is value in what
DNSSEC can provide, they'll presumably pay you for DNSSEC functionality
and if you don't have it, they'll find s
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
I've yet to be shown how DNSSEC is any of those things. D-H key
exchanges, DTLS, DNS PING, all sound far more appealing.
A simple solution that doesn't work always sounds better than a
complex solution that does work, particularly if you anal
David,
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
which you could have argue against 10 years ago but not now.
It's such a shame that computer processing technology for doing
stuff like cryptography hasn't advanced in 10 years.
Unfortunately, the Internet has grown in 10 years, too.
: dnsop@ietf.org WG
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
David Conrad wrote:
>> which you could have argue against 10 years ago but not now.
>
> It's such a shame that computer processing technology for doing stuff
> like cryptography hasn't advanced in 10 yea
David Conrad wrote:
which you could have argue against 10 years ago but not now.
It's such a shame that computer processing technology for doing stuff
like cryptography hasn't advanced in 10 years.
Unfortunately, the Internet has grown in 10 years, too.
Do you want to fund my costs of su
On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
Right. Because low-end consumer gear is always so much better
implemented than enterprise gear.
David Conrad wrote:
> NAT does not need to be modified. As I type this, I am behind a
> commercial (relatively low end -- an Apple Airport Extreme basestation)
> NAT with firewalling enabled. It works just fine.
So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly.
On Aug 18, 2008, at 8:22 PM, Masataka Ohta wrote:
You mean all the DNSSEC clients should directly ask authoritative
nameservers
Yes.
and all the firewalls preventing so should be modified.
The vast majority of firewalls allow 'connections' (even UDP ones) to
be initiated from the inside.
Paul Wouters wrote:
> (distributed) point to point encryption (or validation) is the future!
It's no future.
> I see no problem for port 53 through NAT's.
NAT often captures and modifies packet to port 53.
> But really, so many desktop applications
> do direct DNS now themselves with disregard
On Tue, 19 Aug 2008, Masataka Ohta wrote:
You mean all the DNSSEC clients should directly ask authoritative
nameservers and all the firewalls preventing so should be modified.
(distributed) point to point encryption (or validation) is the future!
Let's assume all the clients agree with you a
David Conrad wrote:
>> If a caching server is required to perform public key computation to
>> verify RRs before caching, it can't support much clients and will be
>> a so easy victim of DDOS.
>
>
> Hence, one of the reasons for the desire to push DNSSEC towards the end
> user.
You mean all t
On Aug 18, 2008, at 5:21 PM, Masataka Ohta wrote:
The fact is DNSSEC is the *only* game in town for preventing cache
poisoning.
Not at all.
Which game do you propose?
If a caching server is not required to perform public key computation
to verify RRs before caching, ...
Then the caching s
Jim Reid wrote:
> The fact is DNSSEC is the *only* game in town for preventing cache
> poisoning.
Not at all.
If a caching server is not required to perform public key computation
to verify RRs before caching, cache poisoning won't be detected by
the caching server, average clients of which su
67 matches
Mail list logo
