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
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
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
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
> 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
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
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
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 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
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
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 wo
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 that unless you are willing to justify the a
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 certif
> 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
___
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 alr
> 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 pointed out, people not intere
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
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.
No, that wasn't my point. My point is th
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 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.
>
> 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 204
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 non-expert in DNSSEC, I have to admit that I am
People who think they don't care about DNSSEC now, should still be
concerned about any changes to root and TLD servers and should be
concerned about the consequences of those changes in the future. There
really are no changes that have zero impact.
> That is, if you don't care about DNSSEC, do
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 data will n
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 _haven
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
c
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 1:01 PM -0700 8/15/08, 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 _haven't_
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 rollover.
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 ke
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 ben
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.
T
62 matches
Mail list logo
