Re: Transition from 2535 to opt-in

[ted@tednet.nl (Ted Lindgreen)]

[Quoting Edward Lewis, on Dec  5, 21:48, in "Re: Transition from  ..."]

> The question of whether "authenticated denial is desired" has been answered
> "yes" a number of times over the past year or so  The question has been
> raised by the WG chair on the list and in person at London.  So it appears
> that there is a desire to provide the service.  (Why?  I don't know.)

I'm sorry, but I may have expressed myself poorly, but this
was not something I was trying to argue against.

I was also present in London and understand why and when authenticated
denial is desired. I also understand that Opt-In does not do away
with authenticated denial.

My question, however is (and also was in London, where an answer
was given, no consensus was reached, as far as I understood);

  "what do we want to achieve with DNSSEC"?

If it is, like Vixie, myself and others argue:

  "To protect the DNS infrastructure"
or said differently:
  "to single out, and get rid of bad RRs in an environment of
   certifyable and intentionally uncertifyable RRs"

then we need authenticated denial. This is to detect when certified
RRs are being replaced by spoofed uncertified RRs. (Please note
that all arguments for the need of authenticated denial, including
the post of Mike Schiraldi in this thread, are about this kind of
attacks).

However, if the goal is, like the author of the current Opt-In
proposal states, and was voiced by quite a number of people at
the off-the-record DNSSEC meeting during the IETF in London:

[Quoting Roy Arends, on Dec  5, 14:04, in "Re: Transition from  ..."]
> ....
>    secure only the RRsets that matter.
>    secure only what needs to be secured.
> ....

then I argue that authenticated denial is not needed, as we now
only need to prove that a certain RR that we want to be secured
verifies. Example:

 I (secure aware user) want to setup an ssh/ipsec tunnel, do
 banking business, or whatever, with you (secure aware site).
 It would be very handy, if I can get the key-info from DNS,
 but I would only use that info when it verifies.
 The same is true for the other side, as you want to make sure
 that I am the one I pretend to be.
 Now there are only two possibilities that matter:
 1. It verifies ==> OK
 2. It does not verify ==> not OK, but further it is totally
    irrelevant whether the info was bad, spoofed, had an
    outdated sig, or was intentionally not secured: for its
    usage it is just not good enough.

The same reasoning comes up for every "RR that matters": you want
it to verify or else it's just worthless. The need for authenticated
denial was to determine whether info is "intentionally not secured"
or "bad", but this distinction is irrellevant for the ""RRs that matter".

Why do a make a big point of it? Probably, because I am also looking
at it from the user/resolver point of view, and not only from the
large TLD point of view.

With our (NLnet Labs) work on designing a secure aware resolver
we found out the hard way, that:
- It is very easy to add a sig-checker and key-chaser to a (stub-)
  resolver to proof that a secured RR verifies or not. This is a
  simple bottom-up procedure:
    get RR/get SIG/get KEY/verify/get SIG of KEY/.. etc. up to
    a KEY we trust.
  For the "secure only the RRsets that matter" approach, this
  is fine and all we need.
- However, to "protect the DNS infrastructure" we need to build
  a resolver, that finds out when secured RRs are being replaced
  by spoofed uncertified RRs. And this is much more difficult.
  It requires a top-down analysis of the DNS tree.  In fact, it
  needs the whole DNS machinery which is now only present in the
  caching forwarders, to be plugged into the stubresolver.

Now, with Opt-In we go implement the whole complex machinery,
but gain only the "secure only the RRsets that matter" goal.
Looking at the added complexity the one hand, and at the gain on
the other, I really think we are on the wrong track.

In conclusion:
 If the goal is "To protect the DNS infrastructure", then
  let us get consensus about that, and we go all the way.
 But, if the goal is "secure only the RRsets that matter"
  let us get consensus about that, then first cleanup the
  complexity not needed anymore, and go that way.

Regards,
-- ted


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.