Subject: simple secure update and signatory strength

From: Brian Wellington <[email-masked]>
Date: Tue, 23 Nov 1999 15:54:36 -0500 (EST)

Hi.  I mentioned at the DNSIND meeting in DC that I'd be opening a
discussion about the merits of the signatory strength field with respect
to simple secure update.  Here goes...

Basically, in the current draft, the 4 bits in the KEY record that
represent signatory strength are interpreted as a 4 bit unsigned integer.
When an update is performed that modifies existing RRsets in a secure
zone, the signatory value of the message must be greater than or equal to
that of the data for the update to occur.

As an example, assume we have a host.example TXT set, signed by a key with
signatory strength 10.  An update signed by a message key with strength
>=10 may update the set (assuming all other checks pass), while a key with
strength <10 may not update the set.

When a set is added/modified, it is signed by the strongest zone key
weaker than or equal to the message signing key.  In the above example, if
the zone keys were of strength 5, 10, and 15, and the message was signed
by a key of strength 12, the zone key of strength 10 would be used.

This allows, for example, a DHCP server to have a key with low strength
but access to all names in a zone, and individuals to have keys with
higher strength and restricted to specific names.  So, if there were no
records for foo.example, the DHCP server could add one, but if I used my
key to add records, the DHCP server could not change my set.  It could
change its own set, though.

The question is, is this useful?  To be of any use, it requires multiple
online zone keys, and the related problem where a signature by any of a
set of zone keys is sufficient to validate a set.  This also adds
complexity to the access control process and extra work for the
administrator when determining whether or not to sign keys if their
signatory strength is too high.

The other argument is that all of this can be done with name-based access
control (granting privileges based on identity), so strength is not
needed.  The DHCP example above could be done by granting permission to
'add' but not 'modify' or 'delete' based on identity, but this might be
more complicated.

I think the signatory field should be left as in ssu-01, but others
disagree and say that the field should remain undefined.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Nov 1999 09:50:47 -0500

>online zone keys, and the related problem where a signature by any of a

This isn't true.  I envision using just one on-line key (eg, strength = 1)
and one (or more) off-line keys (eg, strength = 8).  This would prevent any
dynamic update from modifying some data I want to remain unchanged.

Note: this means that off-line I need a strength = 1 key and a strength = 8
key.
The former is used to sign the SOA, NXT's, and the data subject to dynamic
update.  The latter is used for fixed data (e.g., server addresses,
delegations I don't want to change).

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