Subject: RE: Admitting more documents: application keys in DNS

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 29 Oct 2001 10:41:30 -0800

> > I am disturbed by the apparent proposals to start adding additional
> > demands to DNSSEC before the system is deployed in a form that can
> > secure DNS.
> 
> No additional demands are being made on DNSSEC.  No additional
> security would be required at DNS ops centers simply because the
> APPKEY record exists.

On the contrary, every DNS ops center existing would become a potential
target of a key introduction or substitution attack.

Capture of a DNS server would allow the attacker to compromise all
the applications that rely on it to distribute keys. Since the 
main application you appear to be promoting is SSH that is a very
considerable concern since one of the primary uses of SSH is to 
perform secure admin of UNIX systems.

The vulnerability would be created even for sites that did not
deploy the APPKEY record since SSH clients would be written to
look for the record.

> > I am also somewhat disturbed that a significant proportion of the
> > messages posted in support of the proposal contain statements that
> > appear to indicate limited experience with PKI infrastructure.
> 
> I believe it was just me, on the question of who generates private
> keys in a transaction with a CA (and Andy on the other side of the
> debate, but you don't seem to be bothered that people *against* the
> new infrastructure were also ignorant of aspects of PKI procedures).
> Regardless, this is an ad hominem attack.  If you have something
> substantial to say, say it; don't merely inject FUD into the debate.

I don't think it is unreasonable to expect that people who make
a technical proposal demonstrate knowledge of the subject matter
they are addressing, or at the very least not demonstrate ignorance.

Since the form of your argument is ad-hominem 'trust me we know
what we are doing' you should not get into a tizzy when provided
with a counter-factual.

In the security field the people who oppose a change always get 
favored treatment in the argument over those wanting to make the
change. If you don't like that fact try finding another field. 
'If it works don't break it is' the mantra that every Sysop who 
you repeat your scheme to will reply with.

A half baked security solution is much worse than no security
solution. This half baked solution would introduce a new type
of compromise to an existing security specification that has to
date been reasonably robust.

Before you make a security proposal you need to be able to specify
the assets it is intended to protect, the risks to those assets
it is intended to control, the treats that realise those risks,
the controls that mitigate those risks and convince them that the 
residual risk has substantially decreased.

		Phill

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 29 Oct 2001 22:10:18 -0500

> On the contrary, every DNS ops center existing would become a
> potential target of a key introduction or substitution attack.

Okay, this is a good point.  If code starts looking for more stuff in
DNS, more damage can be done by subverting DNS, even for a domain
which doesn't use the new record types.  I don't think it's a
compelling argument against APPKEY all by itself, but it deserves
careful consideration.

> Since the form of your argument is ad-hominem 'trust me we know what
> we are doing' you should not get into a tizzy when provided with a
> counter-factual.

I don't believe I ever made that argument.  Perhaps someone else made
that argument, or perhaps I unintentionally said something which
sounded like that.  What I was trying to say is:

  * APPKEY is only about fetching keys out of DNS, not putting them
    in.  There is lots of room to do either a good job or a bad job at
    getting keys into the DNS; people should limit themselves to
    imagine one particular procedure.

    At no point did I mean to imply that I was eminently qualified to
    develop procedures to put keys into the DNS, or that the IETF
    should try to standardize those procedures.

  * For many applications, the organization (as reflected by the DNS
    hierarchy) can do a much better job of verifying identities and
    authorizations than a third party can.  Organizations may not
    always do a good job, but they still have the potential to do
    better.

    (For some applications, the reverse would be true.  A CA-issued
    certificate probably makes more sense than a DNS-signed key for
    authenticating a bank, for instance.  Or at least, it would if
    people looked at who certificates were issued to.)