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, appears
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 deterministic
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: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 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 unsigned zones
- 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 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 the
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 a crypto attack on
[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 think this will
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 changes
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!!. Rekeying is out of
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 UDP
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
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 state
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 that,
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 is
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 above should
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 is
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
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 helps
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 to
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
attacker, the
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 Security
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 guys might
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 to
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 answer is
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 only
[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
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 different
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
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
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
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 environment,
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:
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
: 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 years.
Unfortunately, the Internet
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?
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 the DNSSEC
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 of
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.
40 matches
Mail list logo
