Subject: simple-secure-update clarifications

From: Brian Wellington <[email-masked]>
Date: Mon, 12 Jul 1999 16:56:16 -0400 (EDT)

Based on kre's notes and mail from Ed Lewis (who did the presentation), I
have a few comments to make.

A minor naming issue - SSU covers both shared key and public key
authenticated updates.  "Simple" might be a loaded term, and if someone
has a better name, feel free to suggest it.

There were apparently some questions at the meeting about the fact that
simple-secure-update only allows DNS records to be signed by zone keys.  
I'll attempt to better explain the reasoning behind that decision, and
parts of this (and any other comments) will be incorporated into the next
version of the draft.

The primary reason is that this change greatly simplifies the verification
process performed by a resolver.  If only zone keys can sign records, a
resolver must perform the following checks:
  1) Was the SIG generated by a zone key that we trust?
  2) Is the data in the zone whose key signed it?
  3) Is the signature cryptographically correct?
This is fairly straightforward.  If host/user keys can sign DNS records,
the resolver must perform this set of checks:
  1) Was the SIG generated by a key that we trust?
  2) Is the key allowed to sign data (either a zone key or non-zero
     signatory field)?
  3) Is the key allowed to sign THIS data?
  4) Is the signature cryptographically correct?
The main difference is (3), in that there is no mandated policy that
covers delegation of signing authority to non-zone entities.

There shouldn't be such a widespread policy, since different organizations
may delegate signing authority in any way they choose.  If all records are
signed with zone keys, this is not a problem.  Signing records with
non-zone keys is potentially most useful when dealing with dynamic update,
as speficied in RFC2137.  Basically, though, the point is that we want to
allow secure DNS updates signed by keys possessed by non-zone entities.
The server can be configured locally with whatever policies are necessary
to describe whether or not the key is authorized to update the data, and
there is no need to propagate the locally defined policy into the DNS at
large.

There are no real advantages to storing SIG records generated by non-zone
keys as relevant DNS signatures.  Storing SIG records for other protocols
may be useful, but irrelevant to this discussion, since they will be
ignored by end resolvers when doing security checks.  No matter what key
signs a particular record, a resolver must follow a "chain of trust" to a
trusted key.  The chain of trust must pass through a zone key for the zone
containing the data, whether the record was directly signed by the zone
key or an intermediate host/user key.  There's no way to avoid trusting
the zone administrator.

The purpose of DNSSEC is to verifiably prove that data received by a
resolver is the intended data.  It might not be correct, but that's out of
the scope of DNSSEC.  An end resolver won't care about the individual that
controls the record in DNS, but will care about the zone administrator
that controls the zone.  The SIG records should verify that the zone key
has signed the data.  On the other hand, the zone administrator does care
about the individual controlling the record, so the message to the zone
administrator (dynamic update), should be signed with the host/user key.

One argument is that allowing host/user SIGs would allow secure zone to avoid
online zone keys.  The main problem with this is that NXT and SOA records must
be signed by zone keys, so whenever a secure is updated, there must be an
online zone key to resign the SOA and potentially NXT records.

Brian (+ a bit from Olafur)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Jul 1999 03:53:38 -0400

This is a statement that seems like it is a given, but I have been given
feedback that this is not the case.  Some folks have asserted that the zone
admin has a responsibility for making sure data is correct, specifically
when it comes to the KEY RR set.  Where will the employers of zone admins
draw the line wrt the job duties of admin folk?  Will a publisher of KEY
RRs for users make the admin responisble for certifying the keys given?  Or
will the zones prefer the certification carried in X509's slipped into
zones as CERT RR's?

Perhaps this is a debate better suited for bind-workers and/or the DNSOP
mailing list, but I thought I'd try to get DNSEXT opinions first.

>the scope of DNSSEC.  An end resolver won't care about the individual that

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Brian Wellington <[email-masked]>
Date: Tue, 13 Jul 1999 10:55:17 -0400 (EDT)

> mailing list, but I thought I'd try to get DNSEXT opinions first.

DNSSEC is not designed to vouch for the correctness of the data.  It's
designed to prove that the data received is the same as the data entered
into DNS.

Whether the zone administrator is responsible for the correctness of data
is a completely different question, and really is outside the scope of
DNSSEC.  Assuming all of the signatures are correctly formed, the end
resolver will believe the data entered by a remote zone administrator,
whether or not it's correct.

Brian