On Sat, 23 Aug 2008, Mark Andrews wrote:
On Fri, 22 Aug 2008, Mark Andrews wrote:
David do you have a nameserver we can bounce queries off
which has the root zone signed as it would be in production?
VeriSign's root DNSSEC testbed is serving a root zone that is not
modified
On Aug 26, 2008, at 12:08 PM, Matt Larson wrote:
Note that the root-servers.net zone as configured on
root.verisignlabs.com is not signed, since the root-servers.net zone
would not be signed, nor would it need to be, if the root were
signed.
Sorry. Perhaps I need more caffeine. Why not?
On Tue, 26 Aug 2008, David Conrad wrote:
On Aug 26, 2008, at 12:08 PM, Matt Larson wrote:
Note that the root-servers.net zone as configured on
root.verisignlabs.com is not signed, since the root-servers.net zone
would not be signed, nor would it need to be, if the root were
signed.
Sorry.
On Sat, 23 Aug 2008, Mark Andrews wrote:
On Fri, 22 Aug 2008, Mark Andrews wrote:
David do you have a nameserver we can bounce queries off
which has the root zone signed as it would be in production?
VeriSign's root DNSSEC testbed is serving a root zone that
On Aug 26, 2008, at 1:35 PM, Matt Larson wrote:
On Tue, 26 Aug 2008, David Conrad wrote:
On Aug 26, 2008, at 12:08 PM, Matt Larson wrote:
Note that the root-servers.net zone as configured on
root.verisignlabs.com is not signed, since the root-servers.net zone
would not be signed, nor
On Fri, Aug 22, 2008 at 01:22:41PM +1000, Mark Andrews wrote:
Which is why I said look at SE and BR. Their response
profile to DO queries will be the same as the roots assuming
you choose similar key sizes.
See, I think this premise is one for which we have very close to no
Both of Ohta-san's points are entirely valid.
On Ohta-san's first point: DJB is convinced that 1024bit RSA is
crackable with a botnet. And if 1024 isn't crackable now, it probably
will be shortly. So it is probably possible or soon will be possible to
crack keys and then forge many DNSSEC
On Aug 22, 2008, at 6:41 AM, Matt Larson wrote:
What disturbs me is that I detect a disturbing drumbeat of We must
sign the root now--now now NOW! in discussions in various venues.
Such talk doesn't show prudence but panic.
Let's sign the root. But let's do it diligently, always keeping in
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Masataka Ohta
Subject: Re: [DNSOP] A different question
There are intelligent intermediate entities of root, TLD and
other servers between you and authoritative nameservers of your
peer
Antoin Verschuren wrote:
There are intelligent intermediate entities of root, TLD and
other servers between you and authoritative nameservers of your
peer.
This is on data distribution path level, not infrastructure, nor data.
FYI, I of PKI is Infrastructure.
And here are the attacks on
Brian,
On Aug 21, 2008, at 8:45 AM, Brian Dickson wrote:
How stable is the content of the root zone?
(Really, really stable, I'd guess.)
On average, there are about 20-30 changes to the root zone per month
(not including SOA serial number increments) with the trend
increasing. August has
On Thu, 21 Aug 2008, Masataka Ohta wrote:
Instead, MitM attack on DNSSEC is performed, for example, within
intermediate zones with forged signature on child zone with forged
end-users data.
Oh I see. DNSSEC is broken because we cannot trust RSA, DSA, SHA256,
DiffieHellman, and perhaps eliptic
On Thu, Aug 21, 2008 at 09:47:38AM -0700, David Conrad wrote:
...
If the root zone were to strobe between signed and unsigned, what
minimum duration of signed, and what
maximum duration of unsigned would be likely to not cause
operational problems for the aforementioned
DNSSEC-configured
Paul Wouters wrote:
Instead, MitM attack on DNSSEC is performed, for example, within
intermediate zones with forged signature on child zone with forged
end-users data.
Oh I see. DNSSEC is broken because we cannot trust RSA, DSA, SHA256,
DiffieHellman, and perhaps eliptic curve
That is
On Thu, 21 Aug 2008, David Conrad wrote:
Now, I've always thought a separate root infrastructure that you had
to opt in to would be a good way to go, but this quickly gets bogged
down in extremely annoying (at least to me) layer 9 politics and I'll
let someone else try to push that
*plonk*
On Aug 21, 2008, at 3:50 PM, Masataka Ohta wrote:
Paul Wouters wrote:
Instead, MitM attack on DNSSEC is performed, for example, within
intermediate zones with forged signature on child zone with forged
end-users data.
Oh I see. DNSSEC is broken because we cannot trust RSA, DSA,
On Thu, 21 Aug 2008, David Conrad wrote:
Now, I've always thought a separate root infrastructure that you had
to opt in to would be a good way to go, but this quickly gets bogged
down in extremely annoying (at least to me) layer 9 politics and I'll
let someone else try to push that
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
it in their products or services. Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries having
DO
bit on seems a bit high to me) and someone else responded
Jaap Akkerhuis wrote:
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
it in their products or services. Peter Koch did provide an
interesting
data point that warrants further investigation (20-35% of queries
having DO
bit on seems a bit high to me)
On Tue, 19 Aug 2008 15:43:14 -0400, Andrew Sullivan [EMAIL PROTECTED] said:
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
it in their products or services. Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries having DO
bit
* Alexander Gall:
More data points from two authoritative servers for the ch ccTLD:
40-50% (I've attached the relevant DSC graphs for the past month).
I looked more closely on one of the servers. Out of about 22 million
queries in the past 11 hours, about 10 million from 161000 different
Mark Andrews wrote:
DO says that you *understand* DNSSEC and that it is ok to
send a DNSSEC response. It does not mean that you will be
validating the response.
named in all production versions of BIND 9 (9.1.0 onwards)
has set DO on all EDNS queries. BIND
* Masataka Ohta:
Caching servers not validating the response?
Yes, this is still a widely-held view. To be honest, I don't think it
makes much sense. We need DNSSEC right now, not at some unknown
future date when operating system vendors have shipped security-aware,
validating stub resolvers
Florian Weimer wrote:
Anyway, the other problem of DNSSEC is that PKI, as a concept, is
fundamentally broken, against which no PKI protocol can be useful.
I think we need to recast DNSSEC as mere transport protection measure.
It might be a overengineered for this purpose, but
DNSSEC is too
On Aug 20, 2008, at 6:16 AM, Masataka Ohta wrote:
Unlike me, you have no implementation expertise.
Um. Right.
Regards,
-drc
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
David Conrad wrote:
So far, I have seen what appears to be a lot of FUD from Masataka and
the usual concerns/complaints about DNSSEC from folks who haven't
implemented it in their products or services.
Unlike me, you have no implementation expertise.
I did implement server code
Florian Weimer wrote:
Caching servers not validating the response?
Yes, this is still a widely-held view. To be honest, I don't think it
makes much sense. We need DNSSEC right now, not at some unknown
future date when operating system vendors have shipped security-aware,
validating stub
At 5:36 PM +0200 8/20/08, Florian Weimer wrote:
* Masataka Ohta:
Now, I'm saying, for these 10 years, that PKI, including DNSSEC,
is broken.
Can't you simply believe me?
No, because DNSSEC, as it will be deployed, is not a PKI.
Masataka is right that PKI as it is widely used (PKIX) is
In your previous mail you wrote:
So please consider other options before repeating the holy mantra 'DNSSEC is
the only solution'.
= it is not a mantra but the reality:
- transaction protection is not enough if we want to keep caching
in the middle
(the argument is it has to be a
In your previous mail you wrote:
Yes. I've just been told by a fairly authoritative source that BIND
9.5.1 (at least) sets the DO bit on by default, regardless of whether
DNSSEC is configured. This would explain the high number of queries
coming in with DO set.
= as you
Francis,
On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
as you know the DO bit means DNSSEC RRs are accepted, so an
implementation which supports them should set the DO bit.
Mumble.
So, DO=1 by default will result in DNSSEC-related RRs being returned,
regardless of whether those RRs
Florian Weimer wrote:
Caching servers not validating the response?
Yes, this is still a widely-held view. To be honest, I don't think it
makes much sense. We need DNSSEC right now, not at some unknown
future date when operating system vendors have shipped security-aware,
Mark Andrews wrote:
Because DNS is not end to end, DNSSEC is not secure end to end.
Root, TLD and other zones between you and a zone of your peer
are the targets of MitM attacks on DNSSEC.
Which can be removed if needed by exchanging trust anchors
with peers.
You can't.
To
On Aug 20, 2008, at 6:57 PM, Masataka Ohta wrote:
If you and your peer already have secure channel, you have no
reason to use DNSSEC for secure identification nor communication
with the peer.
Ohta-san, this is clueless in so many ways. It's inspiring.
First of all, perhaps you do have a
On Aug 20, 2008, at 6:56 PM, Mark Andrews wrote:
DO is not controlled by dnssec-enable or dnssec-validation.
DNSSEC is designed to be validator to authoritative server.
If you introduce caches then you need to ensure that your
cache is doing something
On Aug 20, 2008, at 7:32 PM, Mark Andrews wrote:
How about years of operation (going back to 9.1.0) without
people even noticing that DO is set. If DO caused non
recoverable problems we would have seen them long before
now.
It would be helpful to have some hard
On Tue, Aug 19, 2008 at 08:55:31AM -0400, Andrew Sullivan wrote:
Now, maybe that doesn't matter for many of these cases. It is
entirely possible that DNSSEC deployment for most zones is just not
worth it. If that's true, however, why are we so worried about poison
attacks?
Because quite a
On Tue, 19 Aug 2008, Andrew Sullivan wrote:
Sure, large organizations with large, mostly competent, and very
conservative IT departments (think banks) will probably not have
this problem and will probably deploy successfully. None of that will
matter, however, if everyone else starts adopting
On Tue, Aug 19, 2008 at 12:07:04PM -0400, Paul Wouters wrote:
Because this is only true for the authorative part of DNSSEC. Since
Dan showed you can cache poison any non-DNSSEC resolver for ANY domain,
not just the domains you are not protecting, you basically have no choice
but to mitigate
On Aug 19, 2008, at 10:00 AM, bert hubert wrote:
In fact, I'm so far not having luck getting around even my 3-year old
primitive anti-spoofing behaviour.
Have you tried dsniff anywhere on the path the DNS packets take?
Regards,
-drc
___
DNSOP
On Tue, Aug 19, 2008 at 01:13:44PM -0400, Paul Wouters wrote:
On Tue, 19 Aug 2008, bert hubert wrote:
In fact, I'm so far not having luck getting around even my 3-year old
primitive anti-spoofing behaviour.
Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to
spoof
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
it in their products or services. Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries having DO
bit on seems a bit high to me) and someone else responded privately that
I
On Aug 19, 2008, at 12:23 PM, bert hubert wrote:
Again - this is about TODAY. DNSSEC might be the end all solution
but even
if it is, it is not deployed widely today and it won't be 12 months
from
now.
Nobody's disputing that point. Is this why we are arguing? The
reason I'm pushing
it in their products or services. Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries having DO
bit on seems a bit high to me) and someone else responded privately that
I think Peter's data point sure warrants further investigation,
On Aug 19, 2008, at 2:09 PM, [EMAIL PROTECTED] wrote:
Peter Koch did provide an interesting
data point that warrants further investigation (20-35% of queries
having DO
bit on seems a bit high to me)
From my own limited investigations (less than 10 servers, but millions
of DNS queries thus
On Fri, Aug 15, 2008 at 04:07:03PM -0700, David Conrad wrote:
intervention) or they'll turn off DNSSEC. So, in the worst case, they'll
get bitten and revert back to the same level of security (or lack thereof)
they have today.
Is this worth blocking DNSSEC deployment?
It seems to me that
On Mon, 18 Aug 2008, Paul Wouters wrote:
I wouldn't be using starbucks resolver, since i just installed my
own DNSSEC-aware resolver?
Ordinarilly , when you get a DHCP-supplied nameserver from starbucks,
your stub resolver directs its requests to that caching server. It is
indeed possible
2008/8/15 David Conrad [EMAIL PROTECTED]:
Hi,
On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote:
But until we have root and .com signed, and until the average end-user is
protected by a validating resolver, we aren't done yet, and I don't really
get any actual benefit from my efforts. Which,
Jaap Akkerhuis wrote:
Given this, does anyone see any DNS security and/or stability concerns
if a miracle were to happen and the root were to be signed tomorrow?
Well,it will introduce a lot of large RRs, which may cause problems.
No, it won't. As David already
Also, a well behavng resolver
has way less request to the root servers then to other servers.
Why, do you think, that servers other than the root servers won't
reply with oversized messages?
Don't twist my words. I never said that.
jaa
On Sat, 16 Aug 2008, Ted Lemon wrote:
On Aug 16, 2008, at 9:35 PM, Dean Anderson wrote:
- If Mal cracks someone else's server, that server still doesn't have
the bank's certificate, and won't have the bank's dns domain, either.
So the browser should think that it got the wrong certificate.
On Sun, 17 Aug 2008, Jaap Akkerhuis wrote:
Also, a well behavng resolver
has way less request to the root servers then to other servers.
Why, do you think, that servers other than the root servers won't
reply with oversized messages?
Don't twist my words. I
Masataka,
No, it won't. As David already pointed out, people not interested
won't
set the DO bit so won't ask for DNSSEC.
I'm talking about people who have, foolishly enough, interested in
DNSSEC and asked for DNSSEC information sometimes in vain.
If they have configured DNSSEC, then they
Mark Andrews wrote:
Considering that two RRs each containing 2048 bit data will need
oversized messages, they may not be properly treated by some
servers.
Those suffering from oversized messages may turn-off DNSSEC and there
is instability for those moving with their laptops.
On Sun, 17 Aug 2008, Ted Lemon wrote:
On Aug 17, 2008, at 9:24 AM, Dean Anderson wrote:
Changing DNS doesn't eliminate the attack of misplaced trust. It
merely eliminates one method we know of for accomplishing the
attack, at great expense and great risk, I might add.
You may not add
On Aug 17, 2008, at 4:12 PM, Dean Anderson wrote:
Changing DNS protocol is considered by many to be expensive and risky.
Are you saying its not expensive or risky? That seems to be a far
more
bold assertion.
Actually, you and Ohta-san seem to be taking that position. That's
not many.
On Sun, 17 Aug 2008, Dean Anderson wrote:
There are two more problems with this.
First, Putting any kind of large record in the root creates the
opportunity to use root servers in a DOS attack by sending queries for
the large records to the root servers. Because of Root Anycasting, there
are
On Sat, 16 Aug 2008, Ted Lemon wrote:
The hype surrounding the Kaminsky report is unjustified. For example,
one can't steal bank information with this attack, as the mainstream
press has reported.
This isn't true, because if I can convince you that a naive user that he or
she is talking to
On Fri, Aug 15, 2008 at 4:51 PM, Paul Hoffman [EMAIL PROTECTED] wrote:
security layers are good. If we don't give those people the right tools to
properly configure and properly maintain those configurations, there will be
stability issues, as I listed earlier.
Let me tell you something.
On Sun, 17 Aug 2008, Ted Lemon wrote:
On Aug 17, 2008, at 4:12 PM, Dean Anderson wrote:
Changing DNS protocol is considered by many to be expensive and risky.
Are you saying its not expensive or risky? That seems to be a far
more
bold assertion.
Actually, you and Ohta-san seem to
On Sun, 17 Aug 2008, Paul Wouters wrote:
On Sun, 17 Aug 2008, Dean Anderson wrote:
There are two more problems with this.
First, Putting any kind of large record in the root creates the
opportunity to use root servers in a DOS attack by sending queries for
the large records to the
On 15 aug 2008, at 22.01, David Conrad wrote:
Let me try to (hopefully) more clearly articulate my question: given
the fact that caching servers only care about DNSSEC if they're
explicitly configured to do so, does anyone anticipate any stability/
security concerns to those folks who
David Conrad wrote:
Given this, does anyone see any DNS security and/or stability concerns
if a miracle were to happen and the root were to be signed tomorrow?
Well,it will introduce a lot of large RRs, which may cause problems.
Considering that two RRs each containing 2048 bit
On Sat, 16 Aug 2008, Ted Lemon wrote:
On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote:
For example, besides the previously mentioned key rollover
issue, I understand that DNSSEC also doesn't allow the protocol to be
changed securely. And we do expect the protocol to be changed.
As a
Mark Andrews wrote:
Considering that two RRs each containing 2048 bit data will need
oversized messages, they may not be properly treated by some
servers.
Those suffering from oversized messages may turn-off DNSSEC and there
is instability for those moving with their laptops.
And how
Hi,
On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote:
But until we have root and .com signed, and until the average end-
user is protected by a validating resolver, we aren't done yet, and
I don't really get any actual benefit from my efforts. Which,
tragically, is why it's taking so long.
On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote:
Hi,
On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote:
But until we have root and .com signed, and until the average end-
user is protected by a validating resolver, we aren't done yet, and
I don't really get any actual benefit
At 11:29 AM -0700 8/15/08, David Conrad wrote:
Given this, does anyone see any DNS security and/or stability
concerns if a miracle were to happen and the root were to be signed
tomorrow?
Yes, at the time of the first root key rollover. Well, to be more
specific, at the time that all of the
Paul,
On Aug 15, 2008, at 12:26 PM, Paul Hoffman wrote:
At 11:29 AM -0700 8/15/08, David Conrad wrote:
Given this, does anyone see any DNS security and/or stability
concerns if a miracle were to happen and the root were to be signed
tomorrow?
Yes, at the time of the first root key
Paul,
On Aug 15, 2008, at 1:51 PM, Paul Hoffman wrote:
If what you really, really mean to ask is given the fact that
caching servers only care about DNSSEC if they're explicitly
configured to do so, does anyone anticipate any stability/security
concerns to those folks who _don't_ configure
At 4:07 PM -0700 8/15/08, David Conrad wrote:
Paul,
On Aug 15, 2008, at 1:51 PM, Paul Hoffman wrote:
If what you really, really mean to ask is given the fact that
caching servers only care about DNSSEC if they're explicitly
configured to do so, does anyone anticipate any stability/security
71 matches
Mail list logo
