DNSSEC - Signature Only vs the MX/A issue.
Mike StJohns
considered.
His question - In the signature only model, what happens if an
attacker does a deletion attack on the MX record at a label forcing
the MTA to fall back to looking up the "A" record?
In PNE, this isn't an issue as you can determine whether or not the
MX record actually existed.
There's a couple of things that should be said here. The MX/A
fallback was simply a hack to deal with the early days of the
internet and the transition from host table to DNS. Most email
accounts were tied to machines on which people had accounts. The PC
as an internet node was still quite a few years away. The host table
model (prior to DNS) basically mapped stj...@umd5.umd.edu to email
on umd5.umd.edu and used the IP address in the host table as the
delivery address. Most MTAs at that point had no concept of MX
records nor did the admins of the various subnets. When DNS came
out, most MTAs still queried only for A records, but eventually
started querying for MX records. At this point in time, I'd be
surprised if there are more than a very few MTAs that don't lead with
MX queries. Anyone have data on any MTAs that don't lead with MX records.
Of course, there may also be zones (or names within zones) that host
MTAs, but that don't also have MX records - anyone have data on this?
I chatted briefly with John Klensin about deprecating this MX/A
alternate in the next revision to RFC2821 - comments on whether this
is a reasonable approach?
Going forward, if an MTA is adapted to use SO, it may be a reasonable
policy to require MX records for a "validated" result. If an MX
record doesn't exist, or if its unsigned, then the output of the
validator would be "unvalidated" regardless of any validation on the
"A" alternate and the MTA would take whatever action is appropriate
for any unvalidated response. The guidance to use MX records would
added to the general guidance for anyone managing an SO zone.
Any other ideas in this general topic?
Mike
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Mark Andrews
> Rob Austein brought up one of the few issues that I hadn't previously
> considered.
>
> His question - In the signature only model, what happens if an
> attacker does a deletion attack on the MX record at a label forcing
> the MTA to fall back to looking up the "A" record?
MX/A/AAAA deletion attack will result in mail bounce that
would otherwise be queued under PNE.
MTA's treat lookup failure differently to non-existance
results. Under SO you will have a lot of mail bounce which
otherwise wouldn't under PNE. If you are clever enough you
can also make the bounce, bounce, leading to silent loss
of the original email.
> In PNE, this isn't an issue as you can determine whether or not the
> MX record actually existed.
>
> There's a couple of things that should be said here. The MX/A
> fallback was simply a hack to deal with the early days of the
> internet and the transition from host table to DNS. Most email
> accounts were tied to machines on which people had accounts. The PC
> as an internet node was still quite a few years away. The host table
> model (prior to DNS) basically mapped stj...@umd5.umd.edu to email
> on umd5.umd.edu and used the IP address in the host table as the
> delivery address. Most MTAs at that point had no concept of MX
> records nor did the admins of the various subnets. When DNS came
> out, most MTAs still queried only for A records, but eventually
> started querying for MX records. At this point in time, I'd be
> surprised if there are more than a very few MTAs that don't lead with
> MX queries. Anyone have data on any MTAs that don't lead with MX records.
There are lots of MX only mail domains. I long ago (+10 years)
stopped worrying about MTAs that don't lookup MX records.
> Of course, there may also be zones (or names within zones) that host
> MTAs, but that don't also have MX records - anyone have data on this?
There are still lots of those.
> I chatted briefly with John Klensin about deprecating this MX/A
> alternate in the next revision to RFC2821 - comments on whether this
> is a reasonable approach?
It would have been if we had said at the start that fallback
was only a N year transition mechanism. These days the
education process would be too hard I think.
> Going forward, if an MTA is adapted to use SO, it may be a reasonable
> policy to require MX records for a "validated" result. If an MX
> record doesn't exist, or if its unsigned, then the output of the
> validator would be "unvalidated" regardless of any validation on the
> "A" alternate and the MTA would take whatever action is appropriate
> for any unvalidated response. The guidance to use MX records would
> added to the general guidance for anyone managing an SO zone.
There will be more than MX records. SRV for lots of services
does / will require PNE.
Anything that is attempting to deliver a robust automated
service needs PNE.
> Any other ideas in this general topic?
>
> Mike
>
>
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Mike StJohns
> > Rob Austein brought up one of the few issues that I hadn't previously
> > considered.
> >
> > His question - In the signature only model, what happens if an
> > attacker does a deletion attack on the MX record at a label forcing
> > the MTA to fall back to looking up the "A" record?
>
> MX/A/AAAA deletion attack will result in mail bounce that
> would otherwise be queued under PNE.
>
> MTA's treat lookup failure differently to non-existance
> results.
It's true that's the policy for existing MTAs (which are non-DNSSEC aware).
>Under SO you will have a lot of mail bounce which
> otherwise wouldn't under PNE.
Not exactly - if you didn't actually consider the problem and
mechanism for mitigating them you might be correct, but that's what
this thread is about. In any event, I think you'll agree that an SO
zone is no worse than an unsigned zone.
> If you are clever enough you
> can also make the bounce, bounce, leading to silent loss
> of the original email.
>
> > In PNE, this isn't an issue as you can determine whether or not the
> > MX record actually existed.
> >
> > > started querying for MX records. At this point in time, I'd be
> > surprised if there are more than a very few MTAs that don't lead with
> > MX queries. Anyone have data on any MTAs that don't lead with MX records.
>
> There are lots of MX only mail domains. I long ago (+10 years)
> stopped worrying about MTAs that don't lookup MX records.
>
> > Of course, there may also be zones (or names within zones) that host
> > MTAs, but that don't also have MX records - anyone have data on this?
>
> There are still lots of those.
>
> > I chatted briefly with John Klensin about deprecating this MX/A
> > alternate in the next revision to RFC2821 - comments on whether this
> > is a reasonable approach?
>
> It would have been if we had said at the start that fallback
> was only a N year transition mechanism. These days the
> education process would be too hard I think.
Looking solely at signed zones, if the strong suggestion were that a
label not have both MX and A records - this could be implemented as
the zones were signed. A DNSSEC-capable MTA would still look for
both records, but would never consider the A records as validated if
they were the only ones retrieved from the label - somewhere between
fully secure and bogus in the way it would be treated.
Regardless of PNE or SO, we need to think about how an MTA would
actually use the DNSSEC data, and that really hasn't happened much yet.
>
> > Going forward, if an MTA is adapted to use SO, it may be a reasonable
> > policy to require MX records for a "validated" result. If an MX
> > record doesn't exist, or if its unsigned, then the output of the
> > validator would be "unvalidated" regardless of any validation on the
> > "A" alternate and the MTA would take whatever action is appropriate
> > for any unvalidated response. The guidance to use MX records would
> > added to the general guidance for anyone managing an SO zone.
>
> There will be more than MX records. SRV for lots of services
> does / will require PNE.
Maybe. MX/A are alternates for each other - both are considered
valid for delivery so the deletion of the MX can still result in a
valid A if the A is signed. SRV records are linear - if any part of
the lookup chain (SRV then A) fails validation, then that chain is
invalid. Deletion of the first part of the chain (e.g. the SRV
records) results in failure not an alternate answer.
Again, this goes under the general discussion of what the policy for
DNSSEC aware applications should be. (And somewhat about how to
handle wildcards)
> Anything that is attempting to deliver a robust automated
> service needs PNE.
This feels to be an assertion rather than a statement of fact. I'd
appreciate an expansion of your reasoning here.
Mike StJohns
atomicity of an RRSet - you can delete ALL of the SRV records or none
of them. If you delete all of them at a label, the lookup fails and
you can't proceed. If you do retrieve the SRV records and then
lookup the referenced A records, the worse that can happen is that
one or more of the individual A records is deleted and an attacker
can steer you to one specific system (from the list of validated names).
At 08:58 AM 11/28/2006, Stephane Bortzmeyer wrote:
>On Sun, Nov 26, 2006 at 10:26:55PM -0500,
> Mike StJohns <Mike.S...@nominum.com> wrote
> a message of 51 lines which said:
>
> > I chatted briefly with John Klensin about deprecating this MX/A
> > alternate in the next revision to RFC2821 - comments on whether this
> > is a reasonable approach?
>
>Unfortunately, there are other records that are vulnerable to this
>attack (SRV, NAPTR), not just MX.
Mark Andrews
> > > alternate in the next revision to RFC2821 - comments on whether this
> > > is a reasonable approach?
> >
> > was only a N year transition mechanism. These days the
> > education process would be too hard I think.
>
> Looking solely at signed zones, if the strong suggestion were that a
> label not have both MX and A records - this could be implemented as
> the zones were signed. A DNSSEC-capable MTA would still look for
> both records, but would never consider the A records as validated if
> they were the only ones retrieved from the label - somewhere between
> fully secure and bogus in the way it would be treated.
Crazy idea.
> Regardless of PNE or SO, we need to think about how an MTA would
> actually use the DNSSEC data, and that really hasn't happened much yet.
>
> >
> > > Going forward, if an MTA is adapted to use SO, it may be a reasonable
> > > policy to require MX records for a "validated" result. If an MX
> > > record doesn't exist, or if its unsigned, then the output of the
> > > validator would be "unvalidated" regardless of any validation on the
> > > "A" alternate and the MTA would take whatever action is appropriate
> > > for any unvalidated response. The guidance to use MX records would
> > > added to the general guidance for anyone managing an SO zone.
> >
> > There will be more than MX records. SRV for lots of services
> > does / will require PNE.
>
> Maybe. MX/A are alternates for each other - both are considered
No, they are not alternates. It is A iff there is no MX.
There are plenty of domains where the MX goes to in house
machine and the A goes to a web servers which is hosted by
a third party.
If you spoof away the existance of the MX then the email
gets delivered to the web hosting box which can be legitimately
running a MTA for its own use.
PNE provides protection against this sort of misdirection.
> valid for delivery so the deletion of the MX can still result in a
> valid A if the A is signed. SRV records are linear - if any part of
> the lookup chain (SRV then A) fails validation, then that chain is
> invalid. Deletion of the first part of the chain (e.g. the SRV
> records) results in failure not an alternate answer.
>
> Again, this goes under the general discussion of what the policy for
> DNSSEC aware applications should be. (And somewhat about how to
> handle wildcards)
>
>
> > Anything that is attempting to deliver a robust automated
> > service needs PNE.
>
> This feels to be an assertion rather than a statement of fact. I'd
> appreciate an expansion of your reasoning here.
Without PNE you just have to blindly trust that a negative
answer is correct. With PNE you have a an assurance that a
negative answer is correct and you can take different steps
to recover when under attack (e.g. log an error and store for
retry).
> > > Any other ideas in this general topic?
> > >
> > > Mike
> > >
> > >
> > >
> > >
> > > --
> > > to unsubscribe send a message to namedroppe...@ops.ietf.org with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://ops.ietf.org/lists/namedroppers/>
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Mike StJohns
>On Tue, Nov 28, 2006 at 03:13:50PM -0500,
> Mike StJohns <Mike.S...@nominum.com> wrote
> a message of 25 lines which said:
>
> > Not exactly. See my previous note to Mark. SO still protects the
> > atomicity of an RRSet - you can delete ALL of the SRV records or
> > none of them. If you delete all of them at a label, the lookup
> > fails and you can't proceed.
>
>the RRset. For instance, in
>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-andrews-http-srv-01.txt,
>there is a fallback from SRV to A.
Couldn't find a copy - the link you provided is bad.
But that brings up a question. Just what atomicity guarantees do you
expect DNSSEC to provide for DNS lookups?
For example - an SRV or NAPTR record at one name can point to a
record at another name - do you expect that the entire group of
related records MUST be signed? If so how do you enforce it,
especially if the references point outside the zone?
If you're talking about A record fall back (e.g. asking for a
SRV/NAPTR/pick one record at www.example.com and falling back to the
A records at www.example.com), what atomicity guarantee do you need
in the temporal dimension? E.g. if I try and retrieve the SRV record
and am told it doesn't exist - securely - but the zone operator is in
the process of installing it and does so before I can retrieve
(perhaps manually) the A record - is that OK even though by the time
I retrieved the A record the SRV record actually did exist? Or worse
yet, the operator was in the process of deleting the A record and
adding the SRV record - I was able to prove when I went to get the
SRV record it didn't exist - when I went to get the A record it also
didn't exist. Both things were true when I asked, but the result is
that for some period of time I will believe that no service exists.
PNE makes the entire zone atomic for some measure of atomicity - what
statement would you make to an application developer about reliance
on that atomicity?
Mike StJohns
>Stephane Bortzmeyer wrote:
> > On Tue, Nov 28, 2006 at 03:13:50PM -0500,
> > Mike StJohns <Mike.S...@nominum.com> wrote
> > a message of 25 lines which said:
> >
> >> Not exactly. See my previous note to Mark. SO still protects the
> >> atomicity of an RRSet - you can delete ALL of the SRV records or
> >> none of them. If you delete all of them at a label, the lookup
> >> fails and you can't proceed.
> >
> > See Peter Koch's reply :-) Many protocols define a fallback outside of
> > the RRset. For instance, in
> >
> http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-andrews-http-srv-01.txt,
> > there is a fallback from SRV to A.
>
>but related name), followed by fallback to A and AAAA.
*sigh* Yes.
Mike StJohns
> > Looking solely at signed zones, if the strong suggestion were that a
> > label not have both MX and A records - this could be implemented as
> > the zones were signed. A DNSSEC-capable MTA would still look for
> > both records, but would never consider the A records as validated if
> > they were the only ones retrieved from the label - somewhere between
> > fully secure and bogus in the way it would be treated.
>
> Crazy idea.
Let me put it another way. A zone with only MX records at a label is
not subject to this deletion attack. Going forward, SO zones would
not have A records at a label that also has MX records.
>
> >
> > Maybe. MX/A are alternates for each other - both are considered
>
> No, they are not alternates. It is A iff there is no MX.
You're correct. I went back and re-read the relevant section of 2821.
On an aside - I think 2821 is wrong. The original "A" mail deliver
hack was designed to deal not with the people implementing the zones,
but with those with old MTAs that were converting over from host
tables and were only using the A record. So 2821 doesn't actually
work for that case - zones aren't required to have MTAs at the A
record. The MX/A hack really needs to be deprecated.
> There are plenty of domains where the MX goes to in house
> machine and the A goes to a web servers which is hosted by
> a third party.
>
> If you spoof away the existance of the MX then the email
> gets delivered to the web hosting box which can be legitimately
> running a MTA for its own use.
>
> PNE provides protection against this sort of misdirection.
Speaking of hacks...
> > > Anything that is attempting to deliver a robust automated
> > > service needs PNE.
> >
> > This feels to be an assertion rather than a statement of fact. I'd
> > appreciate an expansion of your reasoning here.
>
> Without PNE you just have to blindly trust that a negative
> answer is correct. With PNE you have a an assurance that a
> negative answer is correct and you can take different steps
> to recover when under attack (e.g. log an error and store for
> retry).
If I can attack the positive answers, I can attack the negative
answers. If you get a negative, unvalidated answer you do
what? (e.g. MX records doesn't exist - unvalidated - do you try for
the A record, try the MX record again or just fail? The end result -
the mail doesn't get through.)
Mark Andrews
> At 05:56 PM 11/28/2006, Mark Andrews wrote:
> > > Looking solely at signed zones, if the strong suggestion were that a
> > > label not have both MX and A records - this could be implemented as
> > > the zones were signed. A DNSSEC-capable MTA would still look for
> > > both records, but would never consider the A records as validated if
> > > they were the only ones retrieved from the label - somewhere between
> > > fully secure and bogus in the way it would be treated.
> >
> > Crazy idea.
>
> Let me put it another way. A zone with only MX records at a label is
> not subject to this deletion attack. Going forward, SO zones would
> not have A records at a label that also has MX records.
You would then have disjoint sets of mail domains and
hostname rather than the current state of mail domains being
a super set of working (have address records) hostnames.
While I see what you are trying to achieve you are throwing
the baby out with the bath water. I repeat it is a crazy
idea.
Think of the various attack modes. Not all attack modes are
100% reliable. With SO you when you get a negative answer
you *have* to trust it. With PNE you can just drop the bogus
negative answers and try again. Unless the attacker can see
and intercept all your traffic the valid answer will eventually
get through.
With SO you won't be directed to the wrong site, but you can
still be prevented from getting to the site as the result of
a forged DNS response. You can be forced to take a alternate
strategy that you would not normally take.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Mark Andrews
> At 03:47 PM 11/28/2006, Stephane Bortzmeyer wrote:
> >On Tue, Nov 28, 2006 at 03:13:50PM -0500,
> > Mike StJohns <Mike.S...@nominum.com> wrote
> > a message of 25 lines which said:
> >
> > > Not exactly. See my previous note to Mark. SO still protects the
> > > atomicity of an RRSet - you can delete ALL of the SRV records or
> > > none of them. If you delete all of them at a label, the lookup
> > > fails and you can't proceed.
> >
> >See Peter Koch's reply :-) Many protocols define a fallback outside of
> >the RRset. For instance, in
> >http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-andrews-http-sr
> v-01.txt,
> >there is a fallback from SRV to A.
>
>
> But that brings up a question. Just what atomicity guarantees do you
> expect DNSSEC to provide for DNS lookups?
>
> For example - an SRV or NAPTR record at one name can point to a
> record at another name - do you expect that the entire group of
> related records MUST be signed? If so how do you enforce it,
> especially if the references point outside the zone?
I expect each in turn to be signed or provably insecure.
[Anyname not under a trust anchor is provably insecure from
the resolvers perspective.]
> If you're talking about A record fall back (e.g. asking for a
> SRV/NAPTR/pick one record at www.example.com and falling back to the
> A records at www.example.com), what atomicity guarantee do you need
> in the temporal dimension? E.g. if I try and retrieve the SRV record
> and am told it doesn't exist - securely - but the zone operator is in
> the process of installing it and does so before I can retrieve
> (perhaps manually) the A record - is that OK even though by the time
> I retrieved the A record the SRV record actually did exist? Or worse
> yet, the operator was in the process of deleting the A record and
> adding the SRV record - I was able to prove when I went to get the
> SRV record it didn't exist - when I went to get the A record it also
> didn't exist. Both things were true when I asked, but the result is
> that for some period of time I will believe that no service exists.
This not a DNSSEC problem. This is a plain DNS problem. DNSSEC
does not change the problem.
> PNE makes the entire zone atomic for some measure of atomicity - what
> statement would you make to an application developer about reliance
> on that atomicity?
>
>
Mike StJohns
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Paul -
Thanks for your note, and I appreciate it's not an attack on me. You
asked why:
From http://www.whitehouse.gov/omb/circulars/a094/a094.html -
Sunk Cost -- A cost incurred in the past that will not be affected by
any present or future decision. Sunk costs should be ignored in
determining whether a new investment is worthwhile.
The above, although cribbed from a government publication is a good
general business practice - ignoring it is how businesses go bankrupt.
> i for one think that would be a bad idea, both because we
>have invested a lot of time and money in the current design,
Unfortunately, that sentiment seems to be widespread.
The entire development of DNSSEC up to this point is sunk costs - the
amount of investment is no predictor of the success of the
development. After 14 years, with no firm date for completion in
sight and no guarantee that there won't be yet another show stopper -
I think it's reasonable to re-consider the direction, or at least
have some fall back position.
Here's the timeline as I understand it:
~1986 - the Protocol Standards technical panel of the DOD identified
the need to have a way to validate DNS data
~1992-3 - TIS submitted a proposal to ARPA for research in this area
- a 3+ year contract (or maybe a task order against an existing
contract) was awarded.
1999 - DNSSEC was declared done with the publication of RFC2535
2000-2002 - OK, maybe some twiddles - new RFCs covering some changes
- no real deployment of DNSSEC
2003 - Publication of DS RFC
2004 - Typecode rollover discussions
2005 - DNSSEC declared done again with the publication of 4033, 4034, 4035
2005 - OK... maybe not done - NSEC not sufficient for certain zone
operators - some zones (e.g. NL) signed, few signed deletations
2006 - Still working on NSEC3, few signed delegations
2007 - Maybe NSEC3 complete, maybe more show stoppers
So blaming my proposal as a distraction seems to be a bit ...
unreasonable. It may be more reasonable to blame the lack of
attraction of DNSSEC to the zone operators and the lack of any
application driven desire for DNSSEC for its failure to take hold up
to this point.
WRT to Ohta's design - I've actually never seen it. It may be
perfectly fine, but my guess is that it doesn't provide even a hint
of interoperability with the 4033-4035 DNSSEC and I was hoping to at
least use the existing server code base.
In general, my proposal is targeted at the space mostly ignored by
PNE DNSSEC - that of how an application uses signed DNS data. I
don't actually consider this a change in direction, rather one that
could focus this deployment on the use of the data rather than simply
the signing of it for signing's sake.
I've heard the sentiment "Stay the course" too much over the last 4
years -both here and in American politics - the arguments for both
tend to get weaker the longer things go on.
Finally, you asked about 11th hour. When I came back into this 4
years ago people swore it was done and that other proposals weren't
needed. Last year it was "NSEC3 is almost done - have patience" -
the same this year. I actually waited three and a half years on this
or 25% of the total time period. While it may be true that NSEC3 is
almost, I can't predict the future and sunk cost analysis suggest
that I shouldn't attempt to. So the proposal came out after many
patient years. I'm sure if I had submitted this at the beginning of
the NSEC3 discussions I would have gotten the same "11th hour"
comments. So feel free to ignore it - I''ll keep it live as a draft
for a year or so and we can talk about 11th hour issues again in
about a year or two while we're waiting for NSEC4. :-)
You decry my timing and strategy, but I ask you when if not
now? Should I have submitted this as a place holder 3 years ago when
roughly the same argument was made to me? Should I have waited until
NSEC3 was complete - if ever? Never? If the latter really is the
answer, then the IETF is a vastly different organization that it used to be.
Later, Mike
At 05:26 PM 12/2/2006, Paul Vixie wrote:
>i'm having trouble understanding the scope of this discussion. the working
>group refused to consider a simpler design that lacked, among other things,
>secure nxdomain. masataka ohta wrote up a viable proposal 11 years ago and
>the working group went the other direction. now, to the extent that dnssec
>will ever be deployed, the industry as represented in this working group has
>chosen to deploy a more complicated design.
>
>if we are readdressing our original scope, then let's look at masataka ohta's
>simpler design from 11 years ago, and let's stop working on NSEC3 and "white
>lies" and so on. i for one think that would be a bad idea, both because we
>have invested a lot of time and money in the current design, and because i am
>more comfortable with secure denial of existence, even with all its costs.
>
>but this third way forward is mystifying me. i am mystified that msj brought
>it up at all; i am curious to know who, among the deployment communities (who
>are domain holders, domain registrars, domain registries, client implementors,
>server implementors, server operators, and internet governance institutions),
>feels ready to discard the current design at this, the 11th hour (which we
>have already reached and retreated from seven times in 12 years), and move
>back to something that the industry rejected in 1995 or so when eastlake/
>kaufman was chosen over the ohta design. and if we're moving backward, why
>are we reinventing it rather than reusing ohta's perfectly reasonable design?
>
>i am completely amazed to see anyone here arguing technical merits on another
>fundamental change in direction. does anyone really believe that if the ietf
>starts over an 8th time on this technology, that any potential deployer will
>ever again take this working group seriously?
>
>msj, this isn't a personal slam. from a quick glance, your proposal looks to
>be every bit as good as ohta's. the quality of the proposal is not in doubt,
>only the timing and strategy.
>
>re:
>
> > From: Florian Weimer <f...@deneb.enyo.de>
> > To: Mike StJohns <Mike.S...@nominum.com>
> > Cc: namedr...@ops.ietf.org
> > Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
> > Date: Sat, 02 Dec 2006 21:14:18 +0100
> > Sender: owner-nam...@ops.ietf.org
> >
> > * Mike StJohns:
> >
> > > Any other ideas in this general topic?
> >
> > I think this could be addressed in a straightforward manner, keeping
> > the spirit of SO, if you published a signed bitmap of all permitted
> > RTYPE/RCLASS combinations for a particular value.
> >
> > If you wonder if this is worth the additional complexity, it seems to
> > me that this is less complex than the A/MX heuristics described
> > earlier in the thread. At least it's completely deterministic.
> >
> > There is a significant overhead, of course, compared to SO as
> > proposed, but less so compared to plain old DNS.
> >
> > --
> > to unsubscribe send a message to namedroppe...@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/namedroppers/>
>
>--
>to unsubscribe send a message to namedroppe...@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>
--=====================_92570843==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
Hi Paul -<br><br>
Thanks for your note, and I appreciate it's not an attack on me.
You asked why:<br><br>
From
<a href="http://www.whitehouse.gov/omb/circulars/a094/a094.html" eudora="autourl">
http://www.whitehouse.gov/omb/circulars/a094/a094.html</a> - <br><br>
<br>
<b>Sunk Cost</b> -- A cost incurred in the past that will not be affected
by any present or future decision. Sunk costs should be ignored in
determining whether a new investment is worthwhile. <br><br>
The above, although cribbed from a government publication is a good
general business practice - ignoring it is how businesses go
bankrupt.<br><br>
<blockquote type=cite class=cite cite=""> i for one think that would
be a bad idea, both because we<br>
have invested a lot of time and money in the current
design,</blockquote><br>
Unfortunately, that sentiment seems to be widespread.<br><br>
The entire development of DNSSEC up to this point is sunk costs - the
amount of investment is no predictor of the success of the
development. After 14 years, with no firm date for completion in
sight and no guarantee that there won't be yet another show stopper - I
think it's reasonable to re-consider the direction, or at least have some
fall back position. <br><br>
Here's the timeline as I understand it:<br><br>
~1986 - the Protocol Standards technical panel of the DOD identified the
need to have a way to validate DNS data<br>
~1992-3 - TIS submitted a proposal to ARPA for research in this area - a
3+ year contract (or maybe a task order against an existing contract) was
awarded.<br><br>
1999 - DNSSEC was declared done with the publication of RFC2535<br>
2000-2002 - OK, maybe some twiddles - new RFCs covering some changes - no
real deployment of DNSSEC<br>
2003 - Publication of DS RFC<br>
2004 - Typecode rollover discussions<br>
2005 - DNSSEC declared done again with the publication of 4033, 4034,
4035<br>
2005 - OK... maybe not done - NSEC not sufficient for certain zone
operators - some zones (e.g. NL) signed, few signed
deletations<br>
2006 - Still working on NSEC3, few signed delegations<br>
2007 - Maybe NSEC3 complete, maybe more show stoppers<br><br>
<br>
So blaming my proposal as a distraction seems to be a bit ...
unreasonable. It may be more reasonable to blame the lack of
attraction of DNSSEC to the zone operators and the lack of any
application driven desire for DNSSEC for its failure to take hold up to
this point. <br><br>
WRT to Ohta's design - I've actually never seen it. It may be
perfectly fine, but my guess is that it doesn't provide even a hint of
interoperability with the 4033-4035 DNSSEC and I was hoping to at least
use the existing server code base.<br><br>
In general, my proposal is targeted at the space mostly ignored by PNE
DNSSEC - that of how an application uses signed DNS data. I don't
actually consider this a change in direction, rather one that could focus
this deployment on the use of the data rather than simply the signing of
it for signing's sake.<br><br>
I've heard the sentiment "Stay the course" too much over the
last 4 years -both here and in American politics - the arguments for both
tend to get weaker the longer things go on.<br><br>
Finally, you asked about 11th hour. When I came back into this 4
years ago people swore it was done and that other proposals weren't
needed. Last year it was "NSEC3 is almost done - have
patience" - the same this year. I actually waited three and a half
years on this or 25% of the total time period. While it may be true
that NSEC3 is almost, I can't predict the future and sunk cost analysis
suggest that I shouldn't attempt to. So the proposal came out after
many patient years. I'm sure if I had submitted this at the
beginning of the NSEC3 discussions I would have gotten the same
"11th hour" comments. So feel free to ignore it - I''ll
keep it live as a draft for a year or so and we can talk about 11th hour
issues again in about a year or two while we're waiting for NSEC4.
:-) <br><br>
You decry my timing and strategy, but I ask you when if not now?
Should I have submitted this as a place holder 3 years ago when roughly
the same argument was made to me? Should I have waited until NSEC3
was complete - if ever? Never? If the latter really is the
answer, then the IETF is a vastly different organization that it used to
be.<br><br>
Later, Mike<br><br>
<br><br>
At 05:26 PM 12/2/2006, Paul Vixie wrote:<br>
<blockquote type=cite class=cite cite="">i'm having trouble understanding
the scope of this discussion. the working<br>
group refused to consider a simpler design that lacked, among other
things,<br>
secure nxdomain. masataka ohta wrote up a viable proposal 11 years
ago and<br>
the working group went the other direction. now, to the extent that
dnssec<br>
will ever be deployed, the industry as represented in this working group
has<br>
chosen to deploy a more complicated design.<br><br>
if we are readdressing our original scope, then let's look at masataka
ohta's<br>
simpler design from 11 years ago, and let's stop working on NSEC3 and
"white<br>
lies" and so on. i for one think that would be a bad idea,
both because we<br>
have invested a lot of time and money in the current design, and because
i am<br>
more comfortable with secure denial of existence, even with all its
costs.<br><br>
but this third way forward is mystifying me. i am mystified that
msj brought<br>
it up at all; i am curious to know who, among the deployment communities
(who<br>
are domain holders, domain registrars, domain registries, client
implementors,<br>
server implementors, server operators, and internet governance
institutions),<br>
feels ready to discard the current design at this, the 11th hour (which
we<br>
have already reached and retreated from seven times in 12 years), and
move<br>
back to something that the industry rejected in 1995 or so when
eastlake/<br>
kaufman was chosen over the ohta design. and if we're moving
backward, why<br>
are we reinventing it rather than reusing ohta's perfectly reasonable
design?<br><br>
i am completely amazed to see anyone here arguing technical merits on
another<br>
fundamental change in direction. does anyone really believe that if
the ietf<br>
starts over an 8th time on this technology, that any potential deployer
will<br>
ever again take this working group seriously?<br><br>
msj, this isn't a personal slam. from a quick glance, your proposal
looks to<br>
be every bit as good as ohta's. the quality of the proposal is not
in doubt,<br>
only the timing and strategy.<br><br>
re:<br><br>
> From: Florian Weimer <f...@deneb.enyo.de><br>
> To: Mike StJohns <Mike.S...@nominum.com><br>
> Cc: namedr...@ops.ietf.org<br>
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.<br>
> Date: Sat, 02 Dec 2006 21:14:18 +0100<br>
> Sender: owner-nam...@ops.ietf.org<br>
> <br>
> * Mike StJohns:<br>
> <br>
> > Any other ideas in this general topic?<br>
> <br>
> I think this could be addressed in a straightforward manner,
keeping<br>
> the spirit of SO, if you published a signed bitmap of all
permitted<br>
> RTYPE/RCLASS combinations for a particular value.<br>
> <br>
> If you wonder if this is worth the additional complexity, it seems
to<br>
> me that this is less complex than the A/MX heuristics described<br>
> earlier in the thread. At least it's completely
deterministic.<br>
> <br>
> There is a significant overhead, of course, compared to SO as<br>
> proposed, but less so compared to plain old DNS.<br>
> <br>
> --<br>
> to unsubscribe send a message to namedroppe...@ops.ietf.org
with<br>
> the word 'unsubscribe' in a single line as the message text
body.<br>
> archive:
<<a href="http://ops.ietf.org/lists/namedroppers/" eudora="autourl">
http://ops.ietf.org/lists/namedroppers/</a>><br><br>
--<br>
to unsubscribe send a message to namedroppe...@ops.ietf.org
with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive:
<<a href="http://ops.ietf.org/lists/namedroppers/" eudora="autourl">
http://ops.ietf.org/lists/namedroppers/</a>></blockquote></body>
</html>
--=====================_92570843==.ALT--
Edward Lewis
>
(MSJ) > WRT to Ohta's design - I've actually never seen it.
>
>that's a sad statement in and of itself. you're acting like a latecomer who
>has all the answers but hasn't done a lot of research and/or homework. since
>i know you better than that, i am mystified. what kind of
>deployment community
>backing have you received that made your current proposal seem useful?
That's a bit harsh. Ohta's proposal is very hard to find. I've
tried, and eventually did get a copy. Here's a URL for it.
http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
Ralph Droms
organization that is trying to predict customer motivation, which will
predict customer demand for DNSSEC features in our products. We can use
those predictions to guide our decision about when to have those DNSSEC
features ready for our customers.
As far as I can tell, there is no market/commerce motivation today. Attacks
that can be mitigated by DNSSEC are not in the public consciousness like
spam or malware or phishing attacks. Do we have documented evidence of
specific successful attacks that can be mitigated by DNSSEC?
What is the direct, immediate RoI for the resources I have to commit to
providing DNSSEC resolution for names in my zone? My external contacts
("customers") may benefit from mitigation of attacks, but that's an indirect
benefit.
The motivation driving deployment problem is compounded by the complexity
(as measured by the number of moving parts) of the solution, which results
in a chicken-and-egg problem. My organization may benefit by enabling
DNSSEC resolution on my internal hosts and recursive servers, but that
benefit only accrues if the sites I access provide DNSSEC.
The motivation factor seems to be necessary (although not sufficient) to
drive DNSSEC deployment...
- Ralph
On 12/2/06 7:18 PM, "Paul Vixie" <pa...@vix.com> wrote:
>> ... blaming my proposal as a distraction seems to be a bit ...unreasonable.
>> It may be more reasonable to blame the lack of attraction of DNSSEC to the
>> zone operators and the lack of any application driven desire for DNSSEC for
>> its failure to take hold up to this point.
>
> i think the lack of attraction is explainable separately from the quality or
> complexity of the current official design. kc said it best, on one of steve
> crocker's concalls, when steve asked "what's the one thing the community
> needs to begin dnssec deployment?" and kc answered, "motivation." dnssec is
> a classic internet design, demanded by military/government types. it is not
> like the web or ssl, demanded by the market and/or useful for commerce. if
> you're trying to create motivation, then adding an 8th 11th-hour retrenching
> isn't the way. if you're trying to overcome inertia and/or improve the
> cost:benefit toward a more compelling level, then again, adding an 8th 11th
> hour retrenching to the schedule is not your best move.
bert hubert
> that can be mitigated by DNSSEC are not in the public consciousness like
> spam or malware or phishing attacks. Do we have documented evidence of
> specific successful attacks that can be mitigated by DNSSEC?
Yes, there have been succesful spoofing attacks, whereby end-users end up on
a different website from the one they thought they were visiting. These
attacks could have been prevented without DNSSEC however, and any website
that is truly important uses SSL, which would flag the misdirection (which
would then be ignored).
Such spoofing has actually happened a number of times, but hasn't really hit
the news.
It is also easy to do, to quote from
http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt
The calculations above indicate the relative ease with which DNS data can
be spoofed. For example, using the formula derived earlier on a domain
with a 3600 second TTL, an attacker sending 7000 fake answer packets/s (a
rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first
24 hours, which rises to 50% after a week.
For a domain with a TTL of 60 seconds, the 10% level is hit after 24
minutes, 50% after less than 3 hours, 90% after around 9 hours.
I've written some tools that perform this action, when you manage to
saturate the bonafide authoritative servers, success is achieved within
seconds. Partial saturation means somewhat longer time is needed. The
calculations above are for the non-saturated case.
> What is the direct, immediate RoI for the resources I have to commit to
> providing DNSSEC resolution for names in my zone? My external contacts
> ("customers") may benefit from mitigation of attacks, but that's an indirect
> benefit.
They might conceivably worry more over the (inherent) higher reliability
problems of DNSSEC: there are far more failure modes. This is not DNSSECs
fault, it is inherent in any protocol that gets encryption added to it.
This is why I favor (immediate) ameliorization measures, as outlined in my
draft, which are easy to implement.
However, recapping, there IS a problem that needs to be solved.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
Masataka Ohta
> ~1992-3 - TIS submitted a proposal to ARPA for research in this
> area - a 3+ year contract (or maybe a task order against an
> existing contract) was awarded.
It maybe the reason why TIS's proposal was chosen without any
real (Paul's confusion on my proposal is an evidence) discussion.
Stephane Bortzmeyer wrote:
>>the working group refused to consider a simpler design that lacked,
>>among other things, secure nxdomain. masataka ohta wrote up a
>>viable proposal 11 years ago
> Thanks to the archaeologist Ed Lewis, I've read this draft and I'm
> puzzled: it does cover PNE for domains, with the ZL record (and PNE
> for types with the RRD record).
Yese, it does everthing DNSSEC does. The difference is that my
proposal avoided, by design, all the gotchas related to CNAME, glue,
UDP size overflow and so, most of which was confirmed with an
implementation.
OTOH, TIS's proposal was not implemented and was claimed to have
some minor features intentionally missing from mine, all of which
is useless/harmful/impossible and was, later, dropped.
> Ohta's proposal does not seem to be SO
> and therefore does not seem to be a direct competitor of St John's.
It's trivially easy to add my propoal some record that a zone does
not support ZL.
However, even though my proposal makes more simpler to
implement, deploy and operate, the real problem of DNSSEC is
that it is merely weakly secure.
That is, if you can blindly believe that all the namesever
operators between you and your peer are secured, you can blindly
believe that all the ISPs between you and your peer are secured.
Masataka Ohta
bert hubert
> Isn't this always the case with security though? What is the direct, immediate
> RoI for putting a lock on your door?
Try removing the lock from your office building and you find out quickly
enough.
Security IS part of doing business, and if it is more effort than it is
perceived to be worth, people don't do it.
Perception is the key word here though.
My feeling however is that the full cost of DNSSEC (even without NSEC3)
vastly outweighs any perceived (or even: real) benefit.
See http://ds9a.nl/secure-dns.html for some further discussion. I don't
doubt DNS needs better security, but it doesn't warrant anything really
complex.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
Edward Lewis
>spam or malware or phishing attacks. Do we have documented evidence of
>specific successful attacks that can be mitigated by DNSSEC?
I have seen just one attack documented. It isn't like the attack
that Bert Hubert describes, I'll explain that later.
http://www.alvestrand.no/subjects/dns-attack-1.html documents the one
case. This is not a "it could happen" but an attack that did happen.
The attack works on manipulation of data within the registration
system. It could be the result of subscriber fraud (such as using a
fake credit card) or it could be the result of a hiccup in the
registration process.
The hiccup begins with using an out-of-bailiwick name server that is
so out-of-bailiwick the name server is in another domain. There's no
tractable way for the expiration of a domain name to trigger a check
of all uses of name servers in that domain across all other
registries.
A tractable defense to this is to have zones that use out of
bailiwick servers to check on the expiration dates of the domains
homing their slaves. This could be built into a name server product
or a zone management product.
Or completely avoid of out-of-bailiwick name servers. (Peter - I'm
just saying...)
DNSSEC would be one way to address this situation (I wouldn't call it
an attack necessarily), with the alternative being tighter defense
against subscriber fraud and diligent management of out-of-bailiwick
name servers. (Said in the vein that RFC 2181 and the code Andreas
mentioned on the list are an alternative to DNSSEC when fighting
cache poisoning.)
The attack that Bret mentions (I forget if it is a prediction or an
observation - I think it is a prediction because he uses formal math
to describe it) is something that is of concern. But it is cache
poisoning a directed attack at poisoning a particular server. The
situation documented by Harald is a widespread situation, when it is
pulled off, all iterating name servers "will fall victim" to it not
just the targeted one(s).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Edward Lewis
>Perception is the key word here though.
No pun intended, yes, it's all perception.
>My feeling however is that the full cost of DNSSEC (even without NSEC3)
>vastly outweighs any perceived (or even: real) benefit.
Having worked with DNSSEC for more than two years, I know a lot about
what DNSSEC is. But knowing how (well) it is constructed doesn't
mean it is the right solution to the problems we have now.
Times change, problems change. What was probably the best solution
in 1996 might not be the best solution in 2007. Just because DNS has
a vulnerable protocol state and DNSSEC offers a means to defend it
does not mean DNSSEC is the answer.
This doesn't mean DNSSEC ought to be abandoned. But I do wonder why,
if DNSSEC is the solution to problems, that it isn't wholeheartedly
adopted? I don't hear anyone saying "I'd love to use DNSSEC, but
could you adjust it here or there?" I.e., I don't see a building
demand for it.
DNSSEC does take a water-tight approach to security, it would be able
to defend a lot of forms of attack and supports all of the robustness
principles of the DNS (caching, replication, etc.). But is the
effort to be this secure worth the cost? I haven't seen anyone who
says yes to the latter with an open wallet.
bman...@karoshi.com
> DNSSEC does take a water-tight approach to security, it would be able
> to defend a lot of forms of attack and supports all of the robustness
> principles of the DNS (caching, replication, etc.). But is the
> effort to be this secure worth the cost? I haven't seen anyone who
> says yes to the latter with an open wallet.
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-571-434-5468
those w/ open wallets are now w/ empty wallets and nothing (much)
to show for it. :)
--bill
Mike StJohns
> > ... blaming my proposal as a distraction seems to be a bit ...unreasonable.
> > It may be more reasonable to blame the lack of attraction of DNSSEC to the
> > zone operators and the lack of any application driven desire for DNSSEC for
> > its failure to take hold up to this point.
>
>i think the lack of attraction is explainable separately from the quality or
>complexity of the current official design. kc said it best, on one of steve
>crocker's concalls, when steve asked "what's the one thing the community
>needs to begin dnssec deployment?" and kc answered, "motivation." dnssec is
>a classic internet design, demanded by military/government types. it is not
>like the web or ssl, demanded by the market and/or useful for commerce. if
>you're trying to create motivation, then adding an 8th 11th-hour retrenching
>isn't the way. if you're trying to overcome inertia and/or improve the
>cost:benefit toward a more compelling level, then again, adding an 8th 11th
>hour retrenching to the schedule is not your best move.
I'm not adding anything to the schedule.... feel free to complete and
deploy NSEC3 on schedule.. what is that schedule by the way?
> > WRT to Ohta's design - I've actually never seen it.
>
>that's a sad statement in and of itself. you're acting like a latecomer who
>has all the answers but hasn't done a lot of research and/or homework. since
>i know you better than that, i am mystified. what kind of
>deployment community
>backing have you received that made your current proposal seem useful?
I don't think I've ever seen an insult done as subtly and smarmily as
the one above. Congratulations on your use of the English language.
I actually did a fair amount of research and homework as you well
know. I also discussed the generics of my proposal with many people
who have been involved with DNSSEC over the last 4 years and Ohta's
proposal never came up. If it had, having now looked at it, I
wouldn't have used anything from it as it had no interoperability
with 4033-4035. Finally, after I presented SO at the IETF a number
of people who are trying to deploy DNSSEC found me to chat - and said
that this proposal might actually speed deployment.
but you won't improve it by adding an 8th 11th-hour redesign. all you could
>do would be to convince anybody who has been waiting for dnssec that they'll
>have to go their own way.
You seem to be all out of proportion afraid of one simple
proposal. If the DNSSEC train can be derailed by such a simple thing
(think penny on the track) isn't it possible that the track needs
rebuilding or the engine needs redesign?
>are you failing to grasp that any change to the
>way this stuff works will take at least two years to stop arguing about and
>test-in-lab and write code for and so on? and that the real deployment work
>will not begin until those moments stop coming? and that real deployment
>will take five years once it starts?
Actually, given reactions from folks like you I've about decided to
publish it as experimental - as a profile of 4033-4035 with
extensions. That should have it done mostly at the next IETF. For
code - well stub zones without further delegation will run on
4033-4035 compliant servers (already have a few proof of concepts
there). The changes to 4033-4035 authoritative and recursive servers
for full compliance mainly involve teaching them that OSIG should be
treated like RRSIG(DNSKEY) and DSSO like the DS record. For
deployment, if someone thinks they can make money signing OSIG
records I'll bet that would happen sooner than 5 years. For the
application side - that's a bit harder, but since validators for
4033-4035 already exist for a few apps, not as hard as you would
think as SO validation is a subset of PNE validation.
> > You decry my timing and strategy, but I ask you when if not now? Should I
> > have submitted this as a place holder 3 years ago when roughly the same
> > argument was made to me? Should I have waited until NSEC3 was complete -
> > if ever? Never? If the latter really is the answer, then the IETF is a
> > vastly different organization that it used to be.
>
>never. because the IETF is a vastly different organization than it used to
>be. and while you're hitting on the reasons we tried to start MODA, that's a
>separate discussion (and, MODA is dead, since it could not overcome inertia.)
And that's what happens when political considerations override
technical ones... sad.
If you've got further technical arguments to make - please make
them. I'm done with this political thread.
Later, Mike
Mike StJohns
At 01:22 PM 12/4/2006, Robert Story wrote:
>On Mon, 04 Dec 2006 12:12:21 -0500 Mike wrote:
>MS> The changes to 4033-4035 authoritative and recursive servers
>MS> for full compliance mainly involve teaching them that OSIG should be
>MS> treated like RRSIG(DNSKEY) and DSSO like the DS record. For
>MS> deployment, if someone thinks they can make money signing OSIG
>MS> records I'll bet that would happen sooner than 5 years.
>
>I find this interesting, since you've said yourself that you haven't
>figured out a way for a resolver to know if it should expect an OSIG
>record (and thus know if it's been stripped). Which is too bad, I think
>off-tree signing would be very nice to have.
Sorry - apples and oranges here.
The presence of a RRSIG(DNSKEY) hint (e.g. with a special algorithm
type) tells a validator/resolver to look for an OSIG record at the
apex regardless of whether it was returned under a DO query. If it
finds the OSIG, the validator can use the OSIG to create a chain of
trust into the zone.
Under PNE, the presence of a trust anchor implies that I should be
able to complete a proof of existence or non-existence for any query
subordinate to that trust anchor. That's really the first part of
the validation algorithm - setting the expectation before ever
retrieving any data. If the OSIG zone is not under a trust anchor,
then the RRSIG and OSIG could be stripped without ever causing the
PNE validator to reset the expectation from unsigned to signed
resulting the zone being treated as "unknown" or "unsecure"
In SO - all unvalidated answers are equally bad so this isn't a problem.
So you could use this mechanism for PNE, but the results for a zone
signed by OSIG but not subordinate to a trust anchor would be no
better than SO. (Hmm... I guess you could include NSEC records for
the zone, but the signalling for whether a zone is PNE or SO is done
by choice of DS or DSSO so you'd have to encode that in the OSIG).
The way this OSIG/RRSIG hack works is that the OSIG is treated by a
non-SO-compliant server like any other non-dnssec data - (E.g.
RFC3597 master file representation syntax).
Mike
>--
>Robert Story
>SPARTA
bert hubert
> I'm not adding anything to the schedule.... feel free to complete and
> deploy NSEC3 on schedule.. what is that schedule by the way?
Also - if DNSSEC were to be a success, NSEC3 would be the most complex part
of *any* protocol actually used on the internet. It even beats H.323.
Not many protocols require mathematical problem solvers embedded in mission
critical software.
> You seem to be all out of proportion afraid of one simple proposal. If
> the DNSSEC train can be derailed by such a simple thing (think penny on
> the track) isn't it possible that the track needs rebuilding or the engine
> needs redesign?
DNSSEC has been derailed many times already.
Signature Only however might fit the 'cost/benefit' balance.
> Actually, given reactions from folks like you I've about decided to
> publish it as experimental - as a profile of 4033-4035 with
> extensions. That should have it done mostly at the next IETF. For
That is one other problem of DNSSEC - it is absorbing most of the 'brain
cycles' of DNSEXT members. Non-DNSSEC drafts struggle to get enough
attention, even those which would have an immediate positive influence on
DNS security.
Which I understand, a lot of time is needed to work through all DNSSEC
drafts and proposals etc.
But it is sad nonetheless. You may find the same problem getting people
willing to proofread your RFC.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
Mike StJohns
>
>I guess I wasn't clear.. I was referring to this paragraph from your
>initial message on off-tree signing:
>
> > If a DNSSEC aware client makes a query into the DNS tree for data
> > that is not subordinate to one of the trust anchors it knows about
> > (e.g. it olny knows about .COM, the query is for "FOO.NET"), that
> > data is automatically treated as not-signed by the validator. Say
> > that foo.net has an off tree signature - there's no way to convey to
> > the validator that this part of the tree is signed - a simple
> > deletion attack could remove any DNSSEC data and the validator
> > wouldn't know the difference.
>
>So, my observation was simply that I can't imagine people signing up
>for OSIGs when a deletion attack is so simple...
For SO - its a "don't care" or rather "unvalidatable signed data
(e.g. because of deletion) is no better than unsigned data. That's
the basic design of SO.... the only output of the validator is
either validated or unvalidated - if the former, do the "secure"
thing, if the latter do something else.
Mike StJohns
At 02:58 PM 12/4/2006, Mike StJohns wrote:
>>I guess I wasn't clear.. I was referring to this paragraph from your
>>initial message on off-tree signing:
>>
>> > If a DNSSEC aware client makes a query into the DNS tree for data
>> > that is not subordinate to one of the trust anchors it knows about
>> > (e.g. it olny knows about .COM, the query is for "FOO.NET"), that
>> > data is automatically treated as not-signed by the validator. Say
>> > that foo.net has an off tree signature - there's no way to convey to
>> > the validator that this part of the tree is signed - a simple
>> > deletion attack could remove any DNSSEC data and the validator
>> > wouldn't know the difference.
>>
>>So, my observation was simply that I can't imagine people signing up
>>for OSIGs when a deletion attack is so simple...
>
>For SO - its a "don't care" or rather "unvalidatable signed data
>(e.g. because of deletion) is no better than unsigned data. That's
>the basic design of SO.... the only output of the validator is
>either validated or unvalidated - if the former, do the "secure"
>thing, if the latter do something else.
Hmm.. let me expand this.... with the sole exception of a delegation
into an unsecure zone you use PNE to prove that the data you asked
for doesn't exist (NB - at the time you ask). What the practical
result of that is that you won't try and connect (because ...
duh :-) ... you don't have the data).
If you get a valid/exists result in PNE you pretty much never look at
the non-existence data - so this is directly equivalent to SO.
If you get a bogus result (e.g. an inability to either prove or
disprove the existence of data) - that's equivalent to an
"unvalidated" result in SO - both PNE and SO will generally treat
bogus/unvalidated as not secure and take some action less than the
"secure" action.
It's only the corner cases - the provably unsecure set of records
(either not under a trust anchor or under a securely unsecure
delegation) where PNE and SO treat results differently. SO treats
anything that it can't validate as unvalidated. PNE treats data that
it didn't know how to validate as better than data it did know how to
validate, but for which it wasn't able to complete the validation
(e.g. better than bogus data).
Hmm...
bert hubert
> DNSSEC does take a water-tight approach to security, it would be able
> to defend a lot of forms of attack and supports all of the robustness
> principles of the DNS (caching, replication, etc.). But is the
> effort to be this secure worth the cost? I haven't seen anyone who
> says yes to the latter with an open wallet.
We've asked many of our customers and users this exact question: would you
be willing to fund DNSSEC development in PowerDNS, and the answer has so far
always been a resounding 'no'.
We've seen people list "DNSSEC" (w/o further specification) as a
requirement, but nobody clamoured for it enough to pay a (modest) premium
for it.
To put this statement into perspective, in many areas, including some of the
largest internet markets (ie, Germany), PowerDNS controls >50% of domains
right now, and in others over 40% of resolving needs.
So if there were a 'hidden demand' for DNSSEC, or even 'more secure DNS'
we'd heard of it by now.
And I agree fully with Bill Manning's statement that most people previously
willing to fork over money for DNSSEC protocol development now have "an
empty wallet, and nothing (much) to show for it".
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
bert hubert
> So, my observation was simply that I can't imagine people signing up
> for OSIGs when a deletion attack is so simple...
Without intercepting traffic from either the client or the authoritative
nameserver, a deletion attack is only easy if the source port and DNS id of
queries are predictable.
People with the ability to intercept and inject packets are rare compared to
those able to spoof data from non-BCP 38 compliant networks - who I
currently consider the gravest danger to the DNS.
David Blacka
> On Mon, Dec 04, 2006 at 12:12:21PM -0500, Mike StJohns wrote:
>
>> I'm not adding anything to the schedule.... feel free to complete and
>> deploy NSEC3 on schedule.. what is that schedule by the way?
>
> Also - if DNSSEC were to be a success, NSEC3 would be the most complex part
> of *any* protocol actually used on the internet. It even beats H.323.
Er, no.
> Not many protocols require mathematical problem solvers embedded in mission
> critical software.
What are you talking about?
I feel compelled to point out that NSEC3 isn't that complicated to
actually *do*. If it is complex, it is complex to analyze. That is, it
can be hard to convince yourself that it works without a bit of mental
stretching.
--
David Blacka <dav...@verisignlabs.com>
Sr. Engineer VeriSign Infrastructure Product Engineering
bert hubert
> I feel compelled to point out that NSEC3 isn't that complicated to
> actually *do*. If it is complex, it is complex to analyze. That is, it
> can be hard to convince yourself that it works without a bit of mental
> stretching.
It has a 51 page draft, and it details only *non*-existence.
I am referring to NSEC3 non-existence proofs. Perhaps I missed something,
but messages like:
"In practice, then, we must show an NSEC3 record that encloses the hash of
x.C, one that encloses the hash of *.C, and any RR owned by C (which could
be an NSEC3, in which case it would be owned by the hash of C). A resolver
verifying this proof would have to try longer and longer closest enclosers
to determine which was being demonstrated as C, if an NSEC3 is presented.
If any other RR was used, then C would be the owner. Once C has been
determined, the resolver can easily check x.C and *.C against the proof."
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00468.html
.. look rather like I need to solve for a system of constraints within my
software.
But perhaps this applied to a previous draft, of perhaps I am dense (most
likely). The mind boggles however at the failure modes implied by the
wording quoted above.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
David Blacka
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
>> I feel compelled to point out that NSEC3 isn't that complicated to
>> actually *do*. If it is complex, it is complex to analyze. That is, it
>> can be hard to convince yourself that it works without a bit of mental
>> stretching.
>
> It has a 51 page draft, and it details only *non*-existence.
I'm not sure that the length of the draft is totally correlative to the
complexity of the protocol. It certainly took some words and examples
to cover all of the cases, however.
> I am referring to NSEC3 non-existence proofs. Perhaps I missed something,
> but messages like:
>
> "In practice, then, we must show an NSEC3 record that encloses the hash of
> x.C, one that encloses the hash of *.C, and any RR owned by C (which could
> be an NSEC3, in which case it would be owned by the hash of C). A resolver
> verifying this proof would have to try longer and longer closest enclosers
> to determine which was being demonstrated as C, if an NSEC3 is presented.
> If any other RR was used, then C would be the owner. Once C has been
> determined, the resolver can easily check x.C and *.C against the proof."
>
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00468.html
>
> .. look rather like I need to solve for a system of constraints within my
> software.
I don't think that text appears in the any version of the draft.
In any case, all it is actually saying is that you have to iteratively
hash a known, finite series of names in order to determine the closest
encloser. The series of names is the qname, followed by all ancestors
of qname up to and including the zone apex (which you know).
> But perhaps this applied to a previous draft, of perhaps I am dense (most
> likely). The mind boggles however at the failure modes implied by the
> wording quoted above.
The actual proof follows a fairly simple algorithm.
--
David Blacka <dav...@verisignlabs.com>
Sr. Engineer VeriSign Infrastructure Product Engineering
--
Hallam-Baker, Phillip
particulars followed by the complaint that the answers to those =
particulars is too long.
NSEC3 is not at all complex by crypto standards.=20
> -----Original Message-----
> From: owner-nam...@ops.ietf.org=20
> [mailto:owner-nam...@ops.ietf.org] On Behalf Of bert hubert
> Sent: Monday, December 04, 2006 4:38 PM
> To: David Blacka-CR
> Cc: Mike StJohns; Paul Vixie; namedr...@ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
>=20
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
> > I feel compelled to point out that NSEC3 isn't that complicated to=20
> > actually *do*. If it is complex, it is complex to analyze.=20
> That is,=20
> > it can be hard to convince yourself that it works without a bit of=20
> > mental stretching.
>=20
> It has a 51 page draft, and it details only *non*-existence.
>=20
> I am referring to NSEC3 non-existence proofs. Perhaps I=20
> missed something, but messages like:
> =20
> "In practice, then, we must show an NSEC3 record that=20
> encloses the hash of x.C, one that encloses the hash of *.C,=20
> and any RR owned by C (which could be an NSEC3, in which=20
> case it would be owned by the hash of C). A resolver =20
> verifying this proof would have to try longer and longer=20
> closest enclosers to determine which was being demonstrated=20
> as C, if an NSEC3 is presented.
> If any other RR was used, then C would be the owner. Once C=20
> has been determined, the resolver can easily check x.C and=20
> *.C against the proof."
>=20
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/m
> sg00468.html
>=20
> .. look rather like I need to solve for a system of=20
> constraints within my software.
>=20
> But perhaps this applied to a previous draft, of perhaps I am=20
> dense (most likely). The mind boggles however at the failure=20
> modes implied by the wording quoted above.
>=20
> Bert
>=20
> --=20
> http://www.PowerDNS.com Open source, database driven DNS=20
> Software=20
> http://netherlabs.nl Open and Closed source services
>=20
> --
> to unsubscribe send a message to=20
> namedroppe...@ops.ietf.org with the word 'unsubscribe'=20
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>=20
>=20
Hallam-Baker, Phillip
> Isn't this always the case with security though? What is the=20
> direct, immediate RoI for putting a lock on your door?
Rarely from securing an existing infrastructure.
Don't expect the existing uses of DNS to drive deployment of the DNSSEC =
infrastructure. It can only serve those needs after the infrastructure =
is almost complete.
Deployment of DNSSEC will be driven by the deployment of domain centric =
security infrastructure such as DKIM and policy based network =
administrating to address the emerging challenge of deperimeterization.
There is a solid business case there but don't expect early adopters to =
be the ones who are already satisfied.=20
> I think the reason things like DNS and routing security don't=20
> get much traction is because there is much lower hanging=20
> fruit for attackers. If the end points of the Internet=20
> weren't so insecure, then things would be different.
The business case for routing security will be driven by regulation.
> If DNSSEC stabilizes after NSEC3, then DNSSEC could slowly=20
> become part of the BCP for network operators. The blocking=20
> factor here is the TLD (and the root), which has little or=20
> nothing to do with RoI.
Stability is not a necessary condition for deployment. Meeting the =
criterial considered essential by the key infrastructure providers is.
Alex Bligh
--On Monday, December 04, 2006 20:56:25 -0800 "Hallam-Baker, Phillip"
<pba...@verisign.com> wrote:
> Rarely from securing an existing infrastructure.
>
> Don't expect the existing uses of DNS to drive deployment of the DNSSEC
> infrastructure. It can only serve those needs after the infrastructure is
> almost complete.
I'm not sure whether this is the same point Phil is making, but inc ase
not, it seems to me the RoI argument is like expecting positive RoI on the
deployment of the first telephone. From a resolver's point of view,
deployment is not going to be particularly useful until there are a number
of authorative servers with secure data to look up; and from an authorative
server's point of view, deployment isn't particularly useful until there
are a number of secure resolvers who know what to do with the data. Whilst
the above is true, I am also hoping it's so blindlingly obvious (being
equally true for most other end-to-end protocols) that people realized it
15 years ago (*).
As far as "no demand for DNSSEC" is concerned, I think it is fair to say I
have not yet driven through parliament square in London only to be slowed
by hordes of protesters carrying banners saying "what to do want? DNSSEC.
when do we want it? Now. Well, as soon as a reasonable deployment plan can
be worked out". However, I do recall going to a meeting a couple of months
ago attended by (amongst others) by one parliamentarian, and a
representative from the UK Department of Trade and Industry, and being
slightly surprised they where perfectly aware of the possibility of various
DNS-related attacks (no doubt discovered through background reasearch for
other Phishing attacks) and that DNSSEC solved most of them. I suspect that
signifies demand. And I suspect major registries aren't spending time
contributing to drafts simply to keep their staff busy...
(*) = I'm afraid I got a bit lost with the argument that
suggested "can't we validate at the caching resolver instead,
that way we don't have to wait for end users to upgrade". Firstly,
didn't we discover the painful way that middle-boxes are often the
last thing to be upgraded (think about new RR-types and firewalls, etc)?
Secondly, to get proper security functionality out of DNSSEC, doesn't
the end user app need to be upgraded? Or there can be no way it
can distinguish between a signed A record and an unsigned one (let
alone between secure denial and insecure denial); unless I'm missing
something vital, that's pretty much equivalent to no security (sure
the cache itself may be more resistant to some attacks, but we have
plenty of end-user machine attacks now).
Alex
Masataka Ohta
> However, I do recall going to a meeting a couple of months
> ago attended by (amongst others) by one parliamentarian, and a
> representative from the UK Department of Trade and Industry, and being
> slightly surprised they where perfectly aware of the possibility of various
> DNS-related attacks (no doubt discovered through background reasearch for
> other Phishing attacks) and that DNSSEC solved most of them.
That's a big surprise, because DNSSEC is not a protection against
most, if not all, of attacks, even when zone administrators are
not compromised, which is as easy as compromising ISPs.
Perhaps, the parliamentarian should also believe DNSSEC were
cryptographically secure.
Masataka Ohta
Hallam-Baker, Phillip
> From: Alex Bligh [mailto:al...@alex.org.uk]=20
> I'm not sure whether this is the same point Phil is making,=20
> but inc ase not, it seems to me the RoI argument is like=20
> expecting positive RoI on the deployment of the first=20
> telephone.=20
Part of it.
There is a chicken and egg problem in every one of these network effect =
marketting type schemes. So to create critical mass you need to have a =
strategy that does not depend on the network effect.
DKIM has a unilateral deployment advantage albeit a weak one. DKIM + =
Secure Letterhead has a much stronger deployment advantage.
The point here is to design for deployment and in particular to work to =
co-opt the participation of major infrastructure providers, major =
platform providers.
Absolutely nobody has made the claim that NSEC3 is too complex to be =
deployed. Multiple registries have stated that they cannot deploy =
without NSEC3. This is the only group I know where this would still be =
under discussion.
bert hubert
> Absolutely nobody has made the claim that NSEC3 is too complex to be
> deployed.
Let me then make the claim that DNSSEC-bis + NSEC3 is so complex I have
serious worries over its reliable implementability, especially considering
the number of corner cases.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
Hallam-Baker, Phillip
The first is to agree with the Europeans who state that these are =
essential requirements and override Bert on the basis that the =
interoperability results simply do not support his claim.
The second is to shut down DNSSEC completely and immediately: stop =
wasting everyone's time and stop preventing other groups from working on =
this problem.
My vote is for the first approach.
> -----Original Message-----
> From: bert hubert [mailto:bert....@netherlabs.nl]=20
> Sent: Tuesday, December 05, 2006 12:06 PM
> To: Hallam-Baker, Phillip
> Cc: Alex Bligh; shane...@isc.org; Ralph Droms;=20
> namedr...@ops.ietf.org
> Subject: Re: Pimping DNSSEC (was Re: DNSSEC - Signature Only=20
> vs the MX/A issue.)
>=20
> On Tue, Dec 05, 2006 at 07:43:41AM -0800, Hallam-Baker, Phillip wrote:
>=20
> > Absolutely nobody has made the claim that NSEC3 is too=20
> complex to be=20
> > deployed.
>=20
> Let me then make the claim that DNSSEC-bis + NSEC3 is so=20
> complex I have serious worries over its reliable=20
> implementability, especially considering the number of corner cases.
>=20
> Bert
> --=20
> http://www.PowerDNS.com Open source, database driven DNS=20
> Software=20
> http://netherlabs.nl Open and Closed source services
>=20
>=20
Jaap Akkerhuis
The European registries have made it clear that copmpliance
with the EU privacy directive, i.e. compliance with the law is
a higher priority.
Please, don't make sweeping statements about "the european registries".
Not all agree on the need for NSEC3 or similar mechanismes for
"privacy" requirements. Actually, most of them don;t have an opinion
on this, others are happy with classical NSEC.
Furthermore, a european directive is not a law. The implementations
of a directive can be (and most times are) different in the various
member state.
As far as I understand, the UK & DE registries are advised by their
juridical advisors against NSEC because of the local juridical
system.
jaap
Ben Laurie
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
>> I feel compelled to point out that NSEC3 isn't that complicated to
>> can be hard to convince yourself that it works without a bit of mental
>> stretching.
>
> It has a 51 page draft, and it details only *non*-existence.
>
> but messages like:
>
> x.C, one that encloses the hash of *.C, and any RR owned by C (which could
> be an NSEC3, in which case it would be owned by the hash of C). A resolver
> verifying this proof would have to try longer and longer closest enclosers
> to determine which was being demonstrated as C, if an NSEC3 is presented.
> If any other RR was used, then C would be the owner. Once C has been
> determined, the resolver can easily check x.C and *.C against the proof."
>
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00468.html
>
> .. look rather like I need to solve for a system of constraints within my
> software.
>
> likely). The mind boggles however at the failure modes implied by the
> wording quoted above.
I don't see why. All its saying, admittedly at great length, is that you
have to determine the closest encloser.
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Pekka Savola
> That is one other problem of DNSSEC - it is absorbing most of the 'brain
> cycles' of DNSEXT members. Non-DNSSEC drafts struggle to get enough
> attention, even those which would have an immediate positive influence on
> DNS security.
Agree. There are a lot of (IMHO, more) pressing problems with DNS,
such as writing an understandable basic specification (think of 'DNS
implementation requirements') so that 98% of vendors don't get it
wrong (or miss important features, e.g., the cache poisoning
validaton) in one way or the other.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
bert hubert
> Stability is not a necessary condition for deployment. Meeting the
> criterial considered essential by the key infrastructure providers is.
And criterium #1 is stability. I've yet to meet serious infrastructure
providers willing to base their network on unstable protocols, where
unstable means "I'll have to upgrade software/protocols/algorithms in the
foreseeable future".
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
Hallam-Baker, Phillip
> [mailto:owner-nam...@ops.ietf.org] On Behalf Of bert hubert
>=20
> On Mon, Dec 04, 2006 at 08:56:25PM -0800, Hallam-Baker, Phillip wrote:
>=20
> > Stability is not a necessary condition for deployment. Meeting the=20
> > criterial considered essential by the key infrastructure=20
> providers is.
>=20
> And criterium #1 is stability. I've yet to meet serious=20
> infrastructure providers willing to base their network on=20
> unstable protocols, where unstable means "I'll have to=20
> upgrade software/protocols/algorithms in the foreseeable future".
This is simply not true.
The European registries have made it clear that copmpliance with the EU =
privacy directive, i.e. compliance with the law is a higher priority.
VeriSign has made it clear that the efficiency of the protocol, in =
particular the data volumes required is a higher priority.
In any case the way to achieve stability would be to accept maximal =
requirements rather than minimal. We have had an ostrich posture =
specification proposed for ten years with no sign of deployment.
Edward Lewis
>On Mon, 4 Dec 2006, bert hubert wrote:
>> That is one other problem of DNSSEC - it is absorbing most of the 'brain
>> cycles' of DNSEXT members. Non-DNSSEC drafts struggle to get enough
>> attention, even those which would have an immediate positive influence on
>> DNS security.
>
>Agree. There are a lot of (IMHO, more) pressing problems with DNS, such as
>writing an understandable basic specification (think of 'DNS implementation
>requirements') so that 98% of vendors don't get it wrong (or miss important
>features, e.g., the cache poisoning validaton) in one way or the other.
This is one of the many good ideas that has floated to the surface
time and again over the years. Every time this is thought about, we
get caught in what is "right." E.g., look at what happened when we
tried to clarify just AXFR. Clarifying wildcards took 4 years. I'd
rather waste my time designing DNS II than clarifying RFC 1034, et.al.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Alex Bligh
--On 05 December 2006 17:58 +0900 Masataka Ohta
<mo...@necom830.hpcl.titech.ac.jp> wrote:
> That's a big surprise, because DNSSEC is not a protection against
> most, if not all, of attacks, even when zone administrators are
> not compromised, which is as easy as compromising ISPs.
Specifically, DNSSEC is a protection against injection / MITM attacks.
Of course there is the possibility that the zone itself is compromised. But
if you can compromise an ISP, far easier to compromise the web site (which
invariably is the app they are considering) in question.
But even if you are right, and DNSSEC does not protect against the majority
of attacks (for some defined set of attacks) I don't see why that implies
it is not useful; it is a useful component in solving the whole problem
(i.e. securing against that set of attacks).
The alternative rational argument is to say "leave DNS insecure, just
like IP is insecure, solve it all at a higher level, for each protocol,
based on certificates etc., and teach apps that in general DNS alone
cannot be trusted". wc -l /etc/services suggests this is an inefficient
route to take (yes, a gross simplification I know, but you get my point).
Alex
bert hubert
> This is one of the many good ideas that has floated to the surface
> time and again over the years. Every time this is thought about, we
> get caught in what is "right." E.g., look at what happened when we
> tried to clarify just AXFR. Clarifying wildcards took 4 years. I'd
> rather waste my time designing DNS II than clarifying RFC 1034, et.al.
Count me in!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
bert hubert
> > I was in this case only referring to Phillip Hallam-Baker's
> > statement that stability was not a necessary condition for
> > deployment - which statement in my not so humble opinion
> > shows a large "reality gap".
>
> Don't misreprsent me.
I wasn't knowingly doing so. For completeness sake, I might have
misinterpreted your original posting, viz below.
But I'm bowing out of this discussion as I'm afraid we are no longer being
productive.
On Mon, Dec 04, 2006 at 08:56:25PM -0800, Hallam-Baker, Phillip wrote:
> Stability is not a necessary condition for deployment. Meeting the
> criterial considered essential by the key infrastructure providers is.
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01545.html
Hallam-Baker, Phillip
> From: Danny Mayer [mailto:ma...@gis.net]=20
> I suspect that we will see demand for DNSSEC the first time=20
> that a bank sees a poisoning attack and their customers get=20
> redirected to a fake site and their accounts drained as a=20
> result. Phishing attacks can be alleviated since you can tell=20
> technologically that the site is not what it claims. Their=20
> customers will demand it, the bank will be afraid not to do=20
> it, the insurance companies make it a condition of coverage=20
> of losses, etc. Then of course the military have a need for=20
> it. Of course that still leaves the issue of validating=20
> resolvers being not being widely deployed (okay, so only a=20
> handful of people have deployed them).
This attack is happening but not quite in this way.
A spoofing attack only affects a local area. Seems that the use being =
made by the perpetrators of DNS spoofing is to drive folk to fake =
versions of CNN etc. and try to load a trojan onto their machine.
A stolen CC number is worth less than a dollar. Downloading the trojan =
has a higher success rate and pays out rather more.=20
The trojan could be a keystroke logger, a redialer or just recruit as a =
bot.
Masataka Ohta
>> That's a big surprise, because DNSSEC is not a protection against
>> most, if not all, of attacks, even when zone administrators are
>> not compromised, which is as easy as compromising ISPs.
> Specifically, DNSSEC is a protection against injection / MITM attacks.
A man working for zone administrators can be the MITM, just as a
man woking for ISPs can be the MITM.
> The alternative rational argument is to say "leave DNS insecure,
Properly implemented and operated plain DNS is secure.
Properly implemented and operated plain DNS is just as secure
as properly implemented and operated DNSSEC.
Both are weakly secure.
Of course, improperly implemented or operated DNSSEC is less secure
than properly implemented and operated plain DNS.
> solve it all at a higher level, for each protocol,
> based on certificates etc., and
PKI is weakly secure.
You can enjoy cryptographic security only when you directly share
secret information with your peer. Security does cost.
Masataka Ohta
Pekka Savola
>> Agree. There are a lot of (IMHO, more) pressing problems with DNS, such as
>> writing an understandable basic specification (think of 'DNS implementation
>> requirements') so that 98% of vendors don't get it wrong (or miss important
>> features, e.g., the cache poisoning validaton) in one way or the other.
>
> again over the years. Every time this is thought about, we get caught in
> what is "right." E.g., look at what happened when we tried to clarify just
> AXFR. Clarifying wildcards took 4 years. I'd rather waste my time designing
> DNS II than clarifying RFC 1034, et.al.
Yes, I know it's cooler to design new protocols than do maintenance on
the old ones, and I didn't say this would be easy. But if it's too
difficult for us to get agreement on this, how do you think the
implementors will be able to get it right? For overly contentious
topics, one may be able to omit normative specification, but include
some discussion so that the implementor can make an informed decision.
The key point is that I hope that at least 90-95% of DNS
specifications are not contentious and if we are able to recognize
which parts are which, we might be able to make reasonable progress in
finite number of years :-)
I wonder what the implementation and interoperability status of the
basic IP protocols would be without the Host Requirements and Router
Requirements standards.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
Edward Lewis
>Yes, I know it's cooler to design new protocols than do maintenance on the
>old ones, and I didn't say this would be easy. But if it's too difficult for
>us to get agreement on this, how do you think the implementors will be able
>to get it right? For overly contentious topics, one may be able to omit
>normative specification, but include some discussion so that the implementor
>can make an informed decision. The key point is that I hope that at least
>90-95% of DNS specifications are not contentious and if we are able to
>recognize which parts are which, we might be able to make reasonable progress
>in finite number of years :-)
>
>I wonder what the implementation and interoperability status of the basic
>IP protocols would be without the Host Requirements and Router Requirements
>standards.
There are two reasons why I think it is futile to do a mass rewrite
of the DNS protocol as it stands today.
One is that for the most part, it works. Evidence of this is the
huge investment made based upon the existence of the DNS. The domain
name industry is just the first order effect. People fight over
"ownership" of domain names - evidence that there is value in the
name. A lot of advertising money is spent to build value in a domain
name. (Even in the 90's, when a newspaper ran an add that was just
it's WWW service name - a full page, multi-colored printing of the
letters.) What is there is solid enough for industry to make use of
it.
The parts of the DNS that do not interoperate (well) are details that
DNS nerds notice. I wonder if this is just us trying to make work
for us. There are places where there are things to be fixed, but the
marginal benefit in tackling these issues is worth the cost. For
example, when developing the wildcard clarify document, the WG
haggled over what it means to have an NS RRset owned by a wildcard
domain name. In the end, we decided that it was a protocol barb that
wasn't worth the effort to smooth out.
The second reason I think it is foolish to do a major overhaul of the
DNS specification is that a lot of the new functions that are being
demanded from DNS cannot be accommodated in the current architecture.
I've recently blathered about "slapped on security" and problems I
suspect are inherent in that. There's a rising call for limited
search capabilities, something DNS does not accommodate being a
lookup service, that is a reasonable thing to desire but is not
something I can see being fitted into the current protocol.
Non-coherent DNS is another desire. And it could be argued that IDN
is something that DNS doesn't adequately accommodate. (Another case
where we have something that is beneficial but we could have done a
lot better if the protocol was a little bit different.)
A new approach to DNS will happen when two things come together.
When the marginal benefit is greater than the cost there will be
motivation to replace DNS. Part of that, but important enough to be
mentioned separately, is that the new system has to be regulated in
the same way that the DNS is regulated. I.e., the non-protocol
investment in the DNS cannot be undermined.
What does this mean in the DNSEXT WG? To me it makes me think the
work here is pretty much over, just the mopping up of some issues.
I'm not saying shutdown work like NSEC3, SO, and whatever else we
have, but that I don't see this group taking on a major topic and
seeing it come to a change. I'm not against superwildcarding, I am
not optimistic that it can be finished. In the 11 years I've
followed DNSEXT and its forerunners DNSIND and DNSSEC, we've only
managed to get one document to Draft Standard, which I would think is
far easier than slapping on yet another function.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Pekka Savola
> One is that for the most part, it works. [...]
> The parts of the DNS that do not interoperate (well) are details that DNS
We seem to have a different view of what's broken with DNS in the
field. I have seen for example:
- load balancers and such dropping all queries except 'A'
- DNS servers giving various sorts of bogus error codes in various
kinds of conditions (e.g., RFC 4074)
- Totally broken (in various ways) DNS resolvers out there (e.g., RFC
3697)
- various pieces of DNS infrastructure not supporting new RR types as
well as we might like to
- cache poisoning prevention still having no useful normative
specification
- EDNS0 not working very well, e.g., because some products choose
to drop "too big" DNS packets.
Someone better versed with DNS specifications and their
implementations could continue the list.
All of these have contributed to "dumbing down" the minimum, useful
subset of DNS. DNSSEC requires more than the minimum subset, which is
likely one (minor) reason why it likely won't become popular outside
fringe communities ("DNS nerds" you mentioned) any time soon.
> The second reason I think it is foolish to do a major overhaul of the DNS
> specification is that a lot of the new functions that are being demanded from
> DNS cannot be accommodated in the current architecture.
Is your point that revising the specs now isn't worth it because we
can't wrap these new demands in the core DNS spec? Otherwise I didn't
quite understand. Or did you mean that once the core spec is
"opened", worms will sprout out and we'll end up with redesigning the
DNS to accommodate new functions? My intention very specifically was
NOT to include any of these search, IDN, DNSSEC etc. capabilities in
the updated "core DNS" specification.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
Alex Bligh
--On 06 December 2006 17:07 +0900 Masataka Ohta
<mo...@necom830.hpcl.titech.ac.jp> wrote:
> Properly implemented and operated plain DNS is secure.
I would suggest this is a minority view. Else we'd have spent the past
15 years fixing implementations as opposed to protocols.
Alex
Edward Lewis
> - load balancers and such dropping all queries except 'A'
> - DNS servers giving various sorts of bogus error codes in various
> kinds of conditions (e.g., RFC 4074)
> - Totally broken (in various ways) DNS resolvers out there (e.g., RFC
> 3697)
(Do you mean 3697? Flow-label? I don't see DNS in there.)
> - various pieces of DNS infrastructure not supporting new RR types as
> well as we might like to
> - cache poisoning prevention still having no useful normative
> specification
> - EDNS0 not working very well, e.g., because some products choose
> to drop "too big" DNS packets.
I don't discount that this happens or is a pain. But with the
exception of the penultimate point, what part of that is the result
of the protocol specifications being unclear or missing? E.g.,
handling only A records seems like a choice, not a misbelief that
they are the only records in use.
>Someone better versed with DNS specifications and their implementations could
>continue the list.
That seems to be self-contradictory. Folks well-versed probably
can't see what is unclear.
>All of these have contributed to "dumbing down" the minimum, useful subset
>of DNS. DNSSEC requires more than the minimum subset, which is likely one
>(minor) reason why it likely won't become popular outside fringe communities
>("DNS nerds" you mentioned) any time soon.
What's wrong with something being "dumbed down?" Perhaps it is a
sign that the other clutter we've thrown in over the years is
extraneous complexity. The reason why the DNS was built is to
provide a service to others, not be basis for on-going work.
>Is your point that revising the specs now isn't worth it because we can't wrap
>these new demands in the core DNS spec? Otherwise I didn't quite understand.
>Or did you mean that once the core spec is "opened", worms will sprout out
>and we'll end up with redesigning the DNS to accommodate new functions? My
>intention very specifically was NOT to include any of these search, IDN,
>DNSSEC etc. capabilities in the updated "core DNS" specification.
I think that to do some of the new things that are desired cannot be
accommodated in the code now. Part of that is architectural, part of
that is design, part of that is compatibility with the existing base.
Architectural - that DNS is a lookup, not a search. Design - the
CLASS field is after the label. Compatibility - old code won't cope
so we shoe horn unnaturally.
I also don't think we will get agreement on what is in the core now.
I've kicked around the idea of just doing a profile - a document
listing the other documents that define the protocol, and haven't
been able to get any consensus on what is and is not essential. Not
every one likes AXFR, not everyone does CNAME. If we were to
describe what is absolutely necessary for interoperability only in
DNS, we'd get a mudfight.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Pekka Savola
On Wed, 6 Dec 2006, Edward Lewis wrote:
> At 16:39 +0200 12/6/06, Pekka Savola wrote:
>
>> - load balancers and such dropping all queries except 'A'
>> - DNS servers giving various sorts of bogus error codes in various
>> kinds of conditions (e.g., RFC 4074)
>> - Totally broken (in various ways) DNS resolvers out there (e.g., RFC
>> 3697)
>
> (Do you mean 3697? Flow-label? I don't see DNS in there.)
Sorry, 4697.
>> - various pieces of DNS infrastructure not supporting new RR types as
>> well as we might like to
>> - cache poisoning prevention still having no useful normative
>> specification
>> - EDNS0 not working very well, e.g., because some products choose
>> to drop "too big" DNS packets.
>
> I don't discount that this happens or is a pain. But with the exception of
> the penultimate point, what part of that is the result of the protocol
> specifications being unclear or missing? E.g., handling only A records seems
> like a choice, not a misbelief that they are the only records in use.
Almost all of these are due to an insufficiently clear specification,
lack of identification of the "minimum subset of DNS" and to some
degree insufficient motivation ("why is it important to do this?", see
e.g. RFC1812 for examples)
>> All of these have contributed to "dumbing down" the minimum, useful subset
>> of DNS. DNSSEC requires more than the minimum subset, which is likely one
>> (minor) reason why it likely won't become popular outside fringe
>> communities
>> ("DNS nerds" you mentioned) any time soon.
>
> What's wrong with something being "dumbed down?" Perhaps it is a sign that
> the other clutter we've thrown in over the years is extraneous complexity.
> The reason why the DNS was built is to provide a service to others, not be
> basis for on-going work.
The problem is that most of the DNS community and some subset of the
IETF seem to believe the DNS is offering much more than that. If the
specifications only included the "dumbed down" parts (provided that
DNS could still work well enough with those, which I at least I
disagree with), that'd be OK.
This may also be a reason for Keith Moore's rants about unreliability,
slowness etc. of DNS for.., well, pretty much anything :-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
Edward Lewis
>I think I'll be quiet after this post...
I am not trying to be antagonistic. If someone wanted to digitally
remaster the DNS specifications I would applaud the effort. What I
am writing are the reasons why I don't think any effort to do produce
a remastered copy will run to a successful (having a new spec)
completion.
Either we are going to find that there are funds to pay someone or
some small group for the effort to do this or we are going to find a
person (or group) who would rather pursue this at the cost of their
own otherwise free time or this won't happen. Such is the nature of
volunteer efforts.
There is evidence of demand for this work. But that hasn't
translated into action. If someone can drum up support to do this,
great, I would not stand in the way.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Andrew Sullivan
> based on certificates etc., and teach apps that in general DNS alone
> cannot be trusted". wc -l /etc/services suggests this is an inefficient
> route to take (yes, a gross simplification I know, but you get my point).
I get your point, but I'm not really convinced by it. (I'm not
actually convinced of anything in this thread yet, though.)
Suppose I am a DNSSEC contrarian. My argument will go like this
(sorry; it's a little long):
* * *
DNSSEC, including the newer proposals like NSEC3 and SO, places the
security at the wrong point in the network. Application designers
have the responsibility to build the security they need into their
applications. That sometimes means that they can choose not to care
(because loss of data or insecure transmission is acceptable). That
sometimes means that they can choose to provide fairly minimal
security (because, for example, the cost of better security is more
than the value of the data). It sometimes means that users will have
to endure inconvenient out-of-band negotiations of security prior to
connection. And it will sometimes mean that multiple authentication
mechanisms at the ends will be needed (probably with some dependency
on the previous item).
Some will argue that there is inefficiency in that approach, because
several of the security problems could be solved by making the DNS
smarter. But this violates the principle that one should put as much
of the decision making at the edges; DNS is too central to provide
those security services. This is the cost of a dumb network/smart
edge model (which is outweighed by the other benefits).
Some will argue that the application designers will make the wrong
decision (and point to /etc/services as one piece of evidence). But
the failings of previous applications do not entail that some other
part of the Internet should be improved; that is merely an argument
for fixing such applications. And fixing such applications is again
more consistent with pushing as much of the intelligence as possible
out to the edge of the network.
Some will argue that, because there are applications that really need
the security, but whose users simply aren't willing to bear the
inconvenience of multiple-method authentication and out-of-band
mechanisms. I, Contrary Guy, answer that if users aren't willing to
bear such inconvenience, then they have in fact decided that they
don't really want the security after all.
Some will argue that the users of the Internet are not technically
sophisticated enough to do the work of out of band negotiation,
pre-loading of others' certificates, and the like. I, Contrary Guy,
answer that, if such is true, the application designers are shirking
their duty to their users: usability problems are not going to be
solved by remaking the underlying technological support, because the
usability issues will still be there.
Some will argue that the users of the Internet are gullible, and
DNSSEC is needed to protect them. I, Contrary Guy, answer that the
history of tech fixes to solve the problem of human gullibility is
littered with failure, but has no claim to even one success.
Finally, there remains the problem in DNSSEC that the costs of it are
not borne, or are borne at best indirectly, by those who want the
additional security it provides. In order to add this additional
security for some applications, the entire Internet community (or at
least, a significant portion of it) has to bear the burden of
additional load on the DNS and considerably larger DNS packets.
Moreover, several of those who have that burden to bear are either
contractually unable to extract compensation, or are simply too far
from the end to get such compensation from the users. In both cases,
the effect will be that the cost will be temporarily externalized,
and then will be internalized in some other way that distorts the
relationship between service and cost. This distortion is a result
of not following the end to end principle rigourously enough, and
therefore should not be tolerated.
* * *
I want to emphasise that I'm not sure I buy any of the above, but
each of these is one I've heard. Together, they seem to be to be a
pretty strong argument that anything complicated to deliver DNSSEC is
unlikely to prevail (so far, I am unable to come up with much of an
argument to completely counter all of the above). If that's right,
then something less ambitious but simpler, such as the SO approach,
might be a better answer to the extent we think this is a problem
that needs solving.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<and...@ca.afilias.info> M2P 2A8
jabber: aj...@jabber.org +1 416 646 3304 x4110
Hallam-Baker, Phillip
> From: bert hubert [mailto:bert....@netherlabs.nl]=20
> On Tue, Dec 05, 2006 at 11:01:05PM +0000, Alex Bligh wrote:
>=20
> > Noone *has* to upgrade anything. If people don't want to upgrade,=20
> > that's up to them. And I thought your argument (now) was=20
> that it was=20
> > not the protocol that was unstable, but various implementations=20
> > thereof through the complexity of the protocol - in which case they=20
> > will chose the stable implementations instead.
>=20
> I was in this case only referring to Phillip Hallam-Baker's=20
> statement that stability was not a necessary condition for=20
> deployment - which statement in my not so humble opinion=20
> shows a large "reality gap".
Don't misreprsent me.
You said that it was the number 1 criteria. I called bullshit on that =
claim.
I did not say that it was not a criteria I said that it was not the =
number 1 criteria. I don't think it even comes in the top 5.
And regardless I don't think the group can deliver on it. Not when =
people have been ignoring critical functionality.
bert hubert
> Noone *has* to upgrade anything. If people don't want to upgrade, that's up
> to them. And I thought your argument (now) was that it was not the protocol
> that was unstable, but various implementations thereof through the
> complexity of the protocol - in which case they will chose the stable
> implementations instead.
I was in this case only referring to Phillip Hallam-Baker's statement
that stability was not a necessary condition for deployment - which
statement in my not so humble opinion shows a large "reality gap".
Other messages I've written to this list indeed state that I find the
current protocol specs to be very complex, to the extent that I doubt they
can be reliably implemented.
I'm making this last statement having fully experienced how hard it is to
write software even for unsigned DNS, given the many oddities around
(broken middle boxes, "mandatory optional behaviour" etc).
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
Alex Bligh
--On 05 December 2006 08:39 +0100 bert hubert <bert....@netherlabs.nl>
wrote:
> And criterium #1 is stability. I've yet to meet serious infrastructure
> providers willing to base their network on unstable protocols, where
> unstable means "I'll have to upgrade software/protocols/algorithms in the
> foreseeable future".
Noone *has* to upgrade anything. If people don't want to upgrade, that's up
to them. And I thought your argument (now) was that it was not the protocol
that was unstable, but various implementations thereof through the
complexity of the protocol - in which case they will chose the stable
implementations instead.
Alex
Mark Andrews
> Alex Bligh wrote:
>
> >> That's a big surprise, because DNSSEC is not a protection against
> >> most, if not all, of attacks, even when zone administrators are
> >> not compromised, which is as easy as compromising ISPs.
>
> > Specifically, DNSSEC is a protection against injection / MITM attacks.
>
> A man working for zone administrators can be the MITM, just as a
> man woking for ISPs can be the MITM.
>
> > The alternative rational argument is to say "leave DNS insecure,
>
>
> as properly implemented and operated DNSSEC.
>
> Both are weakly secure.
>
> Of course, improperly implemented or operated DNSSEC is less secure
> than properly implemented and operated plain DNS.
>
> > solve it all at a higher level, for each protocol,
>
>
> You can enjoy cryptographic security only when you directly share
> secret information with your peer. Security does cost.
>
> Masataka Ohta
Sure humans could inject data in the pre-sign stage of any
of the parents. This in no different to the occassional
bogus NS RRsets that get added to parents today. I don't
think anyone that knows anything about security would say
that this can't happen. In fact this is the weakest part
of DNSSEC.
On the other has these are rare events compared to the the
attack senarios DNSSEC is designed to protect against.
i.e. spoofed responses.
Now for most zones there are two or three parent zones
that you need to worry about. For those that I've seen
DNSSEC operational plans for I believe them to be secure
against the DNS server machines being compromised. At
worst it results in a DoS attack on the root.
I believe the root can be secured against all but compromised
personel. The root zone is small enough that all data to
be entered can be transfered by hand. There is also a small
enough number of child zones that in person transfers of DS
records will be possible and/or electronic transfers with
backup human to human verification will be possible.
For COM, COM.AU etc. we are going to have to trust that the
registration system won't be compromised. I'm not worried
about the DNS servers themselves being compromised as all
it lead to is a DoS.
AU, UK and other small TLD's are in a similar situation to
the root zone in that it could all be done by hand verification.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Danny Mayer
>
>
> --On Monday, December 04, 2006 20:56:25 -0800 "Hallam-Baker, Phillip"
> <pba...@verisign.com> wrote:
>
>> Rarely from securing an existing infrastructure.
>>
>> Don't expect the existing uses of DNS to drive deployment of the DNSSEC
>> infrastructure. It can only serve those needs after the infrastructure is
>> almost complete.
>
> I'm not sure whether this is the same point Phil is making, but inc ase
> not, it seems to me the RoI argument is like expecting positive RoI on the
> deployment of the first telephone. From a resolver's point of view,
> deployment is not going to be particularly useful until there are a number
> of authorative servers with secure data to look up; and from an authorative
> server's point of view, deployment isn't particularly useful until there
> are a number of secure resolvers who know what to do with the data. Whilst
> the above is true, I am also hoping it's so blindlingly obvious (being
> equally true for most other end-to-end protocols) that people realized it
> 15 years ago (*).
>
> As far as "no demand for DNSSEC" is concerned, I think it is fair to say I
> have not yet driven through parliament square in London only to be slowed
> by hordes of protesters carrying banners saying "what to do want? DNSSEC.
> when do we want it? Now. Well, as soon as a reasonable deployment plan can
> be worked out". However, I do recall going to a meeting a couple of months
> ago attended by (amongst others) by one parliamentarian, and a
> representative from the UK Department of Trade and Industry, and being
> slightly surprised they where perfectly aware of the possibility of various
> DNS-related attacks (no doubt discovered through background reasearch for
> other Phishing attacks) and that DNSSEC solved most of them. I suspect that
> signifies demand. And I suspect major registries aren't spending time
> contributing to drafts simply to keep their staff busy...
>
I suspect that we will see demand for DNSSEC the first time that a bank
sees a poisoning attack and their customers get redirected to a fake
site and their accounts drained as a result. Phishing attacks can be
alleviated since you can tell technologically that the site is not what
it claims. Their customers will demand it, the bank will be afraid not
to do it, the insurance companies make it a condition of coverage of
losses, etc. Then of course the military have a need for it. Of course
that still leaves the issue of validating resolvers being not being
widely deployed (okay, so only a handful of people have deployed them).
That means that Microsoft needs to implement and deploy them as fast as
possible, since they will have, by far, the biggest affect on making
this happen. They are not the only ones of course but it will have the
biggest impact. So where does Microsoft stand in all of this?
Danny
Ralph Droms
e.g. US-CERT? Can you say more about how those attacks could have been
mitigated without DNSSEC? Have there been attacks that could only be
mitigated with DNSSEC?
Of course, a spoofing-phishing attack turns into a DoS attack if the host
discards the bogus DNS info but never gets the DNSSEC validated info.
- Ralph
On 12/3/06 9:53 AM, "bert hubert" <bert....@netherlabs.nl> wrote:
> On Sun, Dec 03, 2006 at 08:10:57AM -0500, Ralph Droms wrote:
>
>> that can be mitigated by DNSSEC are not in the public consciousness like
>> spam or malware or phishing attacks. Do we have documented evidence of
>> specific successful attacks that can be mitigated by DNSSEC?
>
> Yes, there have been succesful spoofing attacks, whereby end-users end up on
> a different website from the one they thought they were visiting. These
> attacks could have been prevented without DNSSEC however, and any website
> that is truly important uses SSL, which would flag the misdirection (which
> would then be ignored).
>
> Such spoofing has actually happened a number of times, but hasn't really hit
> the news.
>
> It is also easy to do, to quote from
> http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt
>
> The calculations above indicate the relative ease with which DNS data can
> be spoofed. For example, using the formula derived earlier on a domain
> with a 3600 second TTL, an attacker sending 7000 fake answer packets/s (a
> rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first
> 24 hours, which rises to 50% after a week.
>
> For a domain with a TTL of 60 seconds, the 10% level is hit after 24
> minutes, 50% after less than 3 hours, 90% after around 9 hours.
>
> I've written some tools that perform this action, when you manage to
> saturate the bonafide authoritative servers, success is achieved within
> seconds. Partial saturation means somewhat longer time is needed. The
> calculations above are for the non-saturated case.
>
>> What is the direct, immediate RoI for the resources I have to commit to
>> providing DNSSEC resolution for names in my zone? My external contacts
>> ("customers") may benefit from mitigation of attacks, but that's an indirect
>> benefit.
>
> They might conceivably worry more over the (inherent) higher reliability
> problems of DNSSEC: there are far more failure modes. This is not DNSSECs
> fault, it is inherent in any protocol that gets encryption added to it.
>
> This is why I favor (immediate) ameliorization measures, as outlined in my
> draft, which are easy to implement.
>
> However, recapping, there IS a problem that needs to be solved.
>
> Bert
Ralph Droms
DNSSEC-aware recursive servers, the DNSSEC-aware host resolvers, signing all
those organization zones, and the fundamental "what's my ROI" question.
I have this vision of a jigsaw puzzle with about 6 or 8 pieces, that we have
to drop from a couple of feet off the ground and have all the pieces land in
place, interlocked, all at once to make DNSSEC fly...
The immediate RoI isn't directly like locking your door, because you don't
have the risk of anything being stolen *directly* from you if you don't
apply DNSSEC to your zones. It's more indirect - somebody else trying to
access your website won't be robbed through a phishing attack if you put a
lock on your door.
- Ralph
On 12/4/06 5:45 AM, "Shane Kerr" <Shane...@isc.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [ Apologies for a mostly non-technical mail that says what everybody already
> knows. ]
>
> Ralph Droms wrote:
>> What is the direct, immediate RoI for the resources I have to commit to
>> providing DNSSEC resolution for names in my zone? My external contacts
>> ("customers") may benefit from mitigation of attacks, but that's an indirect
>> benefit.
>
> Isn't this always the case with security though? What is the direct, immediate
> RoI for putting a lock on your door?
>
> I think the reason things like DNS and routing security don't get much
> traction
> is because there is much lower hanging fruit for attackers. If the end points
> of
> the Internet weren't so insecure, then things would be different.
>
> If DNSSEC stabilizes after NSEC3, then DNSSEC could slowly become part of the
> BCP for network operators. The blocking factor here is the TLD (and the root),
> which has little or nothing to do with RoI.
>
> - --
> Shane
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFc/wuMsfZxBO4kbQRAknGAKCno1hfO/JrNoyhsk+9rkEx94BMRwCginCo
> VWL6Q40W+fGBrmwth3D67ds=
> =Gzje
> -----END PGP SIGNATURE-----
Ted Lemon
> The immediate RoI isn't directly like locking your door, because you don't
> have the risk of anything being stolen *directly* from you if you don't
> apply DNSSEC to your zones. It's more indirect - somebody else trying to
> access your website won't be robbed through a phishing attack if you put a
> lock on your door.
It depends on how much your reputation is worth. I was having dinner
with a guy the other day whose site had been hacked using a SQL
injection attack which resulted in customers' information being acquired
and misused. He certainly didn't think that this was his customer's
problem - indeed, his e-commerce site has been offline for three months
now because they're so worried about the possibility of compromising
their customer info again. DNSSEC doesn't solve this problem at all,
but the point is that companies who don't have a monopoly, which is most
companies, really do care whether their customers' transactions are safe.
Ralph Droms
from customer losses due to fraud, etc. Perhaps those assets are as
tangible as direct theft of cash...
- Ralph
Ben Laurie
> On Dec 6, 2006, at 21:04, Florian Weimer wrote:
>
>> The main reason, IMHO, is that a potential successor (which has to be
>> decoupled from the current DNS to offset itself from its security
>> issues) would hardly inherent most of the legal privileges DNS enjoys.
>
> Perhaps. Though I'm not sure DNS has any legal privileges. DNSv2 would
> surely be doomed by all the layer-9 goop it would attract. Governments,
> regulators, lawyers, industry groups and all sorts of non-technical
> organisations would have a feeding frenzy about who got to control the
> root, where the servers get placed, who gets runs them and how they are
> policed, etc, etc.
What root? ;-)
>> Nobody except a TLD registry operator can get away with such
>> large-scale trademark violations. This card blanche extends down the
>> registrar/reseller pipeline, and it's very hard to compete with *that*.
>
> I disagree with your premise but accept the conclusion. Registrars,
> resellers and the intellectual property folks would scream very loudly
> if there was a viable replacement to the current DNS.
>
> BTW, TLD registry operators don't "get away with trademark violations".
> They're generally innocent third parties. Validating trademarks is hard
> and expensive. [I've just spent months looking at this issue with IPR
> professionals for a new TLD operator.] Even if an impostor registers a
> trade mark, there are a variety of methods for the true holder to gain
> control of the domain. This is now way off topic for this list, so no
> followups on UDRP and suchlike to namedroppers, please...
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>
>
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Edward Lewis
>
>we know there won't be a new namespace. ever. but in addition to adding
>new kinds of names (idn) and securing the data (dnssec) we have sometimes
>tried to improve the protocol (edns). if i were to embark on dnsv2 it would
>be with the hope of completely forklift-upgrading the protocol while keeping
>the namespace as it is.
>
I agree with that. Where I see the discussion getting wrapped around
an axle is when we cross the divide between conveying the data in the
name space with regulating the data in the name space. I've trotted
this out before, there is a difference between talking about DNS and
talking about provisioning of domain names.
It may be hard to see, but every DNS zone is managed by some sort of
registry. Whether it is a formal one like the g/sTLDs of ICANN or a
ccTLD, or just a personal zone with three names in it, there is a
registry. The heart of the registry may be a distributed database or
a text file, the process of generating the zone file may be a
database difference report or the text file may already look like a
zone file.
Coming up with a new wire protocol for DNS would represent about as
much of a change as bring up servers on IPv6 to a registry. DNS is
just a publication mechanism, not what is regulated. Perhaps a new
protocol is more like the transition from LP's to CD's - the music
stayed the same but the cases got smaller. 'Course the analogy
breaks down when you get to MP3's and on-line stores, etc. And
DC-101 (local radio) had to change from "7 album sides at 7" to "7
CD-sides at 7" declaring each half of a CD to be a side.
A cleaned up DNS would present an issue to the regulators - a better
implementation of the CLASS concept. But that's their problem, not
ours. ;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
--
Jay Daley
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
> I think I'll be quiet after this post...
This is an important discussion and you have some interesting things to
say.
DNS certainly has the problem that most people think it is simple to
understand and don't realise there are some real complexities in the
details. This, in my view, explains the astonishing mistakes that many
implementors make.
I think this is going to change as implementors get to grips with DNSSEC.
The complexity of DNSSEC is such that they can't give their DNS work to
the office junior who reads RFC1035 and then thinks that they understand
DNS. Hopefully the trigger of thinking about DNSSEC will force
implementors to address all the bits of DNS they have not yet got around
to understanding.
I'm also increasingly of the view that DNS is /so good/ that most people
simply don't realise it. And it is all those complex and weird little
quirks that enable it to be so good. What worries me about any attempt at
DNSv2 is that some of the brilliance will be lost by trying to 'fix' DNS
and DNS is just too important to work in any less good a way.
Jay Daley
Nominet UK