> 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
> 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 servin
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, n
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.
>
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 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
>
Dean Anderson wrote:
> [Note: increasing key size has
> a corresponding impact on the crypto-overload DOS attack that I
> (Anderson) previously described, and also makes worse the forged query
> DDOS attack that I described.]
It should be noted that new factoring algorithm may make even
64KB key
On Aug 22, 2008, at 11:53 AM, David Conrad wrote:
Specifically, one of the concerns has been that a
separate infrastructure would in some way promote alternate root name
spaces.
It seems to me that the way to avoid this problem is for the
incumbents to step up to the plate.
Another concern
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
mi
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 signatu
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
Matt,
In general I agree with you that due diligence is required and I would
not expect anything different from that, remember how long it take us
to include glues at the root.
On Fri, Aug 22, 2008 at 09:41:21AM -0400, Matt Larson wrote:
> On Fri, 22 Aug 2008, Mark Andrews wrote:
> > Eve
On Fri, 22 Aug 2008, Mark Andrews wrote:
> Every machine that is setting DO is asserting that it can
> handle the responses the roots will generate. These are
> the same sorts of response the servers for SE and BR are
> sending.
I'm not (just) concerned about individual re
On Aug 21, 2008, at 8:41 PM, 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?
ns.iana.org doesn't count as the NS RRset is modified.
I'll see about getting that fixed.
Regards,
-dr
>
> David do you have a nameserver we can bounce queries off
> which has the root zone signed as it would be in production?
>
> ns.iana.org doesn't count as the NS RRset is modified.
>
> Mark
root and root-servers.net to produce worst case senarios.
--
Mark An
David do you have a nameserver we can bounce queries off
which has the root zone signed as it would be in production?
ns.iana.org doesn't count as the NS RRset is modified.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9
> Mark,
>
> On Aug 21, 2008, at 5:25 PM, Mark Andrews wrote:
> > I'm not hoping for the best. I'm confident that there won't
> > be major issues.
> ...
> > Yes change is scary.
>
> This is, perhaps, a question of perspective.
>
> The Internet is now a basic infrastructure upon whic
> 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 p
*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, SHA2
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 bo
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
T
> Andrew Sullivan wrote:
> > On Fri, Aug 22, 2008 at 12:01:16AM +1000, Mark Andrews wrote:
> >
> >
> >> The issues David was pointing out have been visible for years. So
> >> to has the recovery behaviour if one choose to look for it. There
> >> is nothing new in what David has been saying.
>
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
> >DNS
Francis,
On Aug 21, 2008, at 8:42 AM, Francis Dupont wrote:
it seems the three problems are more from EDNS0 than from
the DO=1 (and without EDNSO there is no DO bit :-) so DO is not
the real source of the problems, it is EDNS0 and how it can be
badly handled by not-compliant middle boxes & co.
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
David Conrad wrote:
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
incre
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
Andrew Sullivan wrote:
On Fri, Aug 22, 2008 at 12:01:16AM +1000, Mark Andrews wrote:
The issues David was pointing out have been visible for years. So
to has the recovery behaviour if one choose to look for it. There
is nothing new in what David has been saying.
I think you may be m
In your previous mail you wrote:
The concern I see (that I had hoped would be avoided by DO being set
to 1 only when the caching server administrator had explicitly
configured DNSSEC awareness) is that folks who are blissfully unaware
of the root being signed would, through no f
On Fri, Aug 22, 2008 at 12:01:16AM +1000, Mark Andrews wrote:
> The issues David was pointing out have been visible for years. So
> to has the recovery behaviour if one choose to look for it. There
> is nothing new in what David has been saying.
I think you may be missing the import of what he'
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 attack
On Wed, Aug 20, 2008 at 11:17:38AM +0200, Alexander Gall wrote:
> 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
> >> da
On Thu, Aug 21, 2008 at 12:32:10PM +1000, Mark Andrews wrote:
> people even noticing that DO is set. If DO caused non
> recoverable problems we would have seen them long before
> now.
I don't think that follows, which is (if I interpret him correctly)
what David Conrad was poin
> -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 names
Ted Lemon wrote:
> Ohta-san, if you want to comment on the protocol, you really ought to
> learn how it works first.
I really hope you can learn how to read mails before sending yours.
>> The problem, then, is that the validation is indirectly hop by
>> hop, not end to end.
> This is not how
Ted Lemon 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 secure channel to your
Mark Andrews wrote:
>>To exchange the trust anchors, you need cryptographically secure
>>end to end security, which is not provided by DNSSEC.
>>
>>If you and your peer already have secure channel, you have no
>>reason to use DNSSEC for secure identification nor communication
>>with the peer.
>
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 data
> 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 someth
> 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 peer
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 secu
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 sensible. This
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.
> On Aug 20, 2008, at 6:00 PM, Mark Andrews wrote:
> >Caches will cope with all of the above. There may be some
> >retries. The retries will be logged by some caches. The
> >broken middle boxes will get fixed/replaced.
>
> Mark, is it the case that BIND is setting the D
> Mark Andrews wrote:
>
> >>BTW, DNS is definitely not end-to-end, because it relies on
> >>intelligent intermediate eitities of name servers.
>
> > Actually it doesn't. It can be configured that way but
> > there is no requirement to actually use a caching nameserver.
>
> I'm not talk
On Aug 20, 2008, at 6:00 PM, Mark Andrews wrote:
Caches will cope with all of the above. There may be some
retries. The retries will be logged by some caches. The
broken middle boxes will get fixed/replaced.
Mark, is it the case that BIND is setting the DO bit and then n
> 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
Mark Andrews wrote:
>>BTW, DNS is definitely not end-to-end, because it relies on
>>intelligent intermediate eitities of name servers.
> Actually it doesn't. It can be configured that way but
> there is no requirement to actually use a caching nameserver.
I'm not talking about cachi
In your previous mail you wrote:
Now, I'm saying, for these 10 years, that PKI is broken.
=> what is broken? Crypto, trust model, architecture (including
the RA/CA stuff), etc. There should be many ways to be broken (:-).
That signature generation mechanism is accessible on line does n
> 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,
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 wil
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 kn
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
Florian Weimer wrote:
> No, because DNSSEC, as it will be deployed, is not a PKI. There is no
> registration process which is universally agreed upon.
A PKI with a universally agreed registration process of "it depends"
is still a PKI.
However, a problem of PKI is that, even if such a process i
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 b
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 s
* 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. There is no
registration process which is universally agreed upon. As a result, a
DNSSEC signature carries
Mark Andrews wrote:
> The current DNSSEC essentially matches "Simple Secure DNS".
Well, mostly. Thank you for your pointer to RFC4035 I ignored.
And, congratulations that the WG has wasted only 10 years of
implementation and operational experiences to reach the
conclusion that the original
> * 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,
> validatin
> 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
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
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 t
* 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
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. BI
* Masataka Ohta:
> 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 it's what we've got
n
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 for my
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 9.1.1 onwards name
* 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 differen
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
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 hi
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
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 h
> > 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 investig
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 D
On Tue, Aug 19, 2008 at 10:09:16AM -0700, David Conrad wrote:
> 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?
Not
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 th
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
Andrew,
On Aug 19, 2008, at 5:55 AM, Andrew Sullivan wrote:
If some technology is going to be deployed, there is generally a
business reason for that to happen.
This is also true, but in my experience one of those business reasons
is, depressingly often, "This is the Current Thinking I read in
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 based on bogus query types, since PowerDNS dropped those packets a
On Tue, 19 Aug 2008, bert hubert wrote:
Is there some sort of shield preventing people from reading or even arguing
with
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html
?
All those things can be done today, unilaterally, and they start working
from the moment you enab
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 mailin
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 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 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
On Mon, Aug 18, 2008 at 03:47:46PM -0700, David Conrad wrote:
> In today's Internet, most network engineers (at least at real companies)
> don't go turning on new, weird technologies for fun.
This is true.
> If some technology is going to be deployed, there is generally a
> business reason fo
Andrew,
On Aug 18, 2008, at 6:29 AM, Andrew Sullivan wrote:
When the CTO receives the incident report, the CTO is going to say,
"So if
we never turned on DNSSEC, this wouldn't have happened? Ok. New
policy: no DNSSEC."
In today's Internet, most network engineers (at least at real
compani
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 th
At 4:46 PM +0200 8/18/08, Peter Koch wrote:
Of course, one might claim that anybody using ANY in any production system
(pun intended) gets what they deserve.
Fully agree. Maybe a BCP document titled "Asking for ANY Considered
Unwise" would be useful.
--Paul Hoffman, Director
--VPN Consortium
On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote:
> However, because of DO, folks who don't configure their resolvers to
> do DNSSEC shouldn't ever see any DNSSEC goop.
so, one question is whether the "DO" bit actually signals understanding of
the correct version of DNSSEC and what
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
This is not the case, but if so, why would you bootstrap a DNSSEC
enabled server using a non-DNSSEC forwarder?
You haven't been following along with the discussion. There may be
DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might
use DNSSEC-oblivious intermediate caches. Fo
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 record
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
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 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 y
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 ov
On Fri, 15 Aug 2008, 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 _h
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, 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 no
> 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
1 - 100 of 123 matches
Mail list logo
