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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 29 Oct 2001 09:16:23 -0800

Both sets of statements appear to be confused.

As a CA the last thing I ever want to see is someone's private key. The
liabililty issues involved in that type of process are just horrendous.

It is of course essential that the CA know that the person registering the
public key be the actual holder of the private key. Otherwise there are a
bunch of nasty certificate substitution attacks possible. Fortunately with
public key crypto it is not necessary to reveal the private key to prove
that I know it, hence the proof of possession mechanisms.

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. We
are not going to be able to deploy DNSSEC if Price Waterhouse and the rest
go round telling the F500 companies that they require Tier 5 security for
their DNS ops centers if they turn it on.

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. It is the same feeling I get
when talking to X.500 biggots who rant on about how the world has to move to
the one true name system while showing a complete lack of knowledge of what
DNS does and how it works.

The trust provided by a PKI is not determined by the technical mechanisms
employed, they merely set the lower bound for the trust provided. It is the
administrative procedures that provide the trust. 

Trust is the ability to accurately asses risk. An established system that
has a proven track record will always have a significant advantage over a
newly proposed one.

While any administrative procedure must inevitably have some failure rate,
some are more error prone than others. There are 250,000 SSL certs current.
The reported reliability of the admin proceedures is 99.999%.

PKI is not easy. The DNS is now a critical infrastructure. Do not
underestimate the difficulty of deploying a security infrastructre, a change
to a critical infrastructure, a security infrastructure that requires a
change to a critical infrastructure.

It may well prove to be the case that to deploy DNSSEC it is necessary to
make changes to it. By deploy I mean "cause to be used by at least 10% of
the DNS user base" and not "implement in some copy of BIND". 

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Greg Hudson [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 6:02 PM
> To: Andy W. Barclay
> Cc: namedroppers
> Subject: Re: Admitting more documents: application keys in DNS
> 
> 
> > If I get an ssh key from DNS, even if that key has been signed by
> > DNSSec, then I still can't trust it. Why? Because I can be pretty
> > sure that the user generated his/her own key pair, then forwarded
> > the public key to the admin for inclusion to the DNS.
> [...]
> > Without a CERT, I can't be sure of the identity of the user. 
> 
> So, let me get this straight:
> 
>   A DNS APPKEY record retrieved via secure DNS is a key signed by the
>   next level up in the DNS hierarchy.  An APPKEY record must have been
>   signed by an irresponsible DNS administrator who got the public key
>   from some other person by an unauthenticated path.
> 
>   A certificate is a key signed by the next level up in the
>   certification hierarchy.  A certificate key must have been signed
>   by a responsible CA who generated the key pair and transmitted the
>   private key to some other person by a secret path.
> 
> That's a pretty impressive level of prejudice, given that the
> technical mechanisms are identical.

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 12:54:13 -0500

> 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.

> 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.

> The trust provided by a PKI is not determined by the technical
> mechanisms employed, they merely set the lower bound for the trust
> provided. It is the administrative procedures that provide the
> trust.

(I believe you mean an upper bound.)

Yes, administrative procedures provide the trust.  But the IETF
specifies technical mechanisms, not administrative procedures.  And
the APPKEY RR specification has nothing to do with how these keys are
entered into the DNS.  If you believe that the APPKEY mechanism sets
an unacceptable upper bound on trust, make a concrete argument.

> An established system that has a proven track record will always
> have a significant advantage over a newly proposed one.
[...]
> There are 250,000 SSL certs current.  The reported reliability of
> the admin proceedures is 99.999%.

In my observation, these procedures have really only been proven for
the operation commercial web sites--one certificate per organization.
250,000 is meaninglessly small compared to the number of certificates
which would need to be out there to handle the full range of
interactions which ought to be cryptographically protected.

I agree that APPKEY has a pretty big hill to climb to create a
globally scalable and reasonably secure cryptographic infrastructure.
This working group might kill it (for reasons I still can't quite
understand).  Even if APPKEY goes forward, DNSSEC might never be
deployed at the root.  Even if that happens, new APPKEY-using
protocols might never be designed or accepted which could rival TLS.
And even if they are, a good set of administrative procedures might
never grow up around them.

On the other hand, even if DNSSEC is never deployed at the root, and
no TLS-like protocol arises using DNSSEC-protected keys, organizations
could still use APPKEY records and preconfigured DNSSEC keys to secure
SSH keys internally, without having to mess around with X.509
certificates.  I think that's useful enough just by itself to justify
APPKEY going forward.