Subject: Please state the 'attacks' in public

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Sun, 9 Jun 2002 10:04:14 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>Well, these attacks were only brought to my attention in Minneapolis.
>I believe that Roy and Rob are writing up a document and personally
>I am waiting to see what it says. I believe that Rob knows about this
>attack, and I'm fairly sure that Roy does as well.

Forgive me for asking for raising the same issue yet again, perhaps if
the substantive issues were addressed there would not be the need.

What are the security issues that Roy and Rob are addressing?

Why can they not be shared with the group as a whole?

If the AD needs advice on the security of OPTIN it would be more productive
to address those concerns to one of the people who has done an extensive
security analysis already.

My understanding from certain members of the cabal is that what Roy and Rob
have actually been asked to do is rehash the work on the necessity of the
protocol change.

I don't think that second guessing the working group on that issue is a
proper matter for the cabal.

As for Randy's splutterings about Black Helicopters, the existence of
false conspiracy theories does not disprove the existence of conspiracies.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Derek Atkins <[email-masked]>
Date: 09 Jun 2002 22:23:10 -0400

> Why can they not be shared with the group as a whole?

Phill, when Roy and Rob finish the document I'm sure it will be
published as an I-D for all to read.  These security issues "cannot be
shared with the group as a whole" because, currently, they are in the
brains of Rob and Roy, and are not written down.  Patience, Phill.
Take a deep breath, relax, and let Rob and Roy finish their document.
There is no malice involved here, Phill.  Just relax -- nobody here is
out to get you.  When they finish, don't worry, you'll know.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Jun 2002 11:40:17 +0200 (CEST)

> What are the security issues that Roy and Rob are addressing?

The process of caching/resolving opt-in material is not well understood.
There is a potential burdon on a resolving nameserver which previously has
cached opt-in NXT records.

In 2535, NXT records will only appear in a "negative" response (as in:this
record does not exist).

With DS, NXT records appear in a "positive" response (in the case where
NXT states: no DS). In that case, the owner name of the NXT record is
identical to the QNAME.

With Optin, NXT-Opt-in records (NXT without NXT bit set), appear in both
"positive" responses and "negative" responses.

Historically, nameservers use different internal-cache-lookup algorithms
for both negative and positive responses.

A memory efficient nameserver would cache NXT only once. Question: Is it
okay to synthesize positive responses with negative responses. Since the
TTL has different properties for both forward and reverse, this has the
potential to be very ugly. It may even lead to security issues.

There is another issue: When a nameserver has cached a positive Opt-In
response: unsigned "www.example.com A" record set in an Optin zone.  NXT
record states "aaa.example.com NXT zzz.example.com ..."; the NXT record
makes a statement for all between aaa and zzz. The owner name of the NXT
record does NOT match the owner name of the A record set. Now, a choice
between two evils should be made:

 1) Match an incoming query with the owner name of the NXT record. This
    leads to verifying and caching of all unique QNAME/QTYPE combinations
    between aaa and zzz.example.com, including all NXT records and their
    accompanying signature. This is potentially putting the burdon from
    authoritative nameservers to recursive nameservers. Needless to say,
    this is inefficient, since there is a lot of redundant
    crypto-verification. Getting rid of crypto-redundancy was one of the
    design principles of opt-in.

 2) Match an incoming query to the NXT records owner/nxt-owner interval.
    This is unique in the history of positive caching. Also an extra
    burdon on the ca hing server.

A third issue that was brought up was how the AD bit should be
interpreted. The AD bit says (short answer) all records have been verified
to be okay. One one hand, with opt-in, there is an unsigned record which
cannot be verified that it is "okay" -> AD bit clear. On the other hand,
there is an unsigned record which can be verified that it is not signed ->
AD bit set. In both cases, ALL signatures have been checked. ALL
"crypto-statements" have been verified, and still, both AD bit states can
be appropriate. Though the AD bit is a minor issue, this has to be written
very clear and unambigous.

The last issue "The typo attack" is absolutely no issue. It is discussed
to death !!!! Since one uses opt-in, unsigned/unverified/untrue records
can and may appear in the NXT-Optin interval. This should be clear before
using opt-in. As with everything: if it is not signed, who knows what the
state of the record is. No "security holes" are opened here. One has to
decide consciously to use opt-in.

> Why can they not be shared with the group as a whole?

The whole "directorate push-back" hype was as follows:

Rob Austein mentioned some of the above open issues. At that moment there
was simply no written material about this (or none to my knowledge). The
IESG annual meeting was coming up two weeks ago, Rob would be there, and
some other folk who tend to show some clue once in a while were there as
well. I happen to live in Holland, and Randy saw this as a good
opportunity to have a face to face on this. A few folk there were also
part of this dns-directorate. The list of names is known and is/was no
secret. The conclusion was simply that the above issues needed to be
documented. Rob and I volunteered to do this, and will do so. No hush
hush, no secrets. We simply wanted to write this, and publish it, then
discuss this on namedroppers, instead of discussing air. From that moment,
I was added to this directorate. This way, Rob and I could discuss this
matter while others could listen in. We might have chosen to do this in a
private mail discussion. We did not. We might have chosen to discuss this
on namedroppers, with a big potential of polarizing this whole discussion
yet again, causing more delay. We did not.

However. "Push back of the directorate" is a big misnomer. When I first
heard about this "push-back" I was mad as hell. What directorate ?
Who are they ? This was IMHO totally against NOTE WELL. If the directory
had any such power, it should be dismanteld.

"Push-back of the directorate" essentially means that the WG-chairs had
to extend D-Day on opt-in once again, while we're writing this doc. Brave
thing to do, since there is an enormous pressure on deploying DNSSEC
yesterday.

Turns out to be push-back as in "Deadline postponed yet once more". Not
Optin is dead. Randy could have spend some more words about this.

If any of you (really, anyone) can bring up design flaws in Opt-in that
opens security holes due to protocol bugs, please do so, you will safe me
a lot of work and pain.

So, in short. Rob and I are going to write these issues up issues up.
These issues are not (!) related to the opt-in, but simply issues that can
pop-up due to the fact that these corner-cases are not well understood,
and might be interpreted the wrong way.

This document has nothing to do with directorates whatsoever. Once its
finished, its dumped on namedroppers.

> have actually been asked to do is rehash the work on the necessity of the

No, absolutely not. We were asked to address the above cases which are not
well understood, and might cause ambiguity in deployment. IMHO the
necessity of the protocol change is crystal clear.

Roy

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 17:22:44 +0200 (CEST)

> security analysis already.

Where are the results of this analysis written down?

Thanks,
   Erik