Re: Signalling DS support to resolvers

[Olafur Gudmundsson <ogud@ogud.com>]

On Wed, 10 Oct 2001, Olaf Kolkman wrote:

> 
> 
> My 0.02 Euro (only about 80 days to go before we can actually 'pay')
> 
> I would like to see the SEC RR to be used for this, it seems a clean
> design and the idea to have to set the flag on ANY of the ZONE keys
> seems error prone.
> 
> Those arguments are not good enough to make a engineering decision so
> here comes another argument:
> 
> In addition the SEC RR could be stored to store some additional
> administrative details about the ZONE's security. Let me try to
> explain shortly, I want to write this out in more detail in a draft
> but since that will take a week or two (or more) here follows a small
> braindump.

This is a good idea, and we need to figure out how the
SEC record should look like given that we want options that can
have extra data associated with them. 
The long term goal is to be able down the road to have any 
resolver parse all options correctly including the ones it does
not understand (sounds familiar). 

Question: How complex/simple does the SEC RR have to be ? 

Olaf mentioned that the <DS option> needs additional data 
in this case 32 bits (yes 8 bits will not be used) 

Is there need for strings ? 

Is there need for number/bit field of size other than 32 bits ? 
One possible answer: we may want to list the addresses of authorative 
servers and IPv6 addresses are 128 bits. 


> 
> We are trying to design a system for automatic "trusted-keys"
> rollover. The first iteration of this idea was published as
> draft-ietf-dnsop-resolver-rollover. With DS the concept of keyset
> signing keys was introduced. You could call that key the secure entry
> point to a zone, it is the key that the parents point to with DS and
> that resolvers can have preconfigured. The method described in the
> draft would not be able to distinguish between these
> 'secure-entry-point' keys and keys that are used for signing and may
> rollover with relatively high frequency. I am thinking about how to
> indicate to resolvers which key is the secure entry point. During
> automatic rollovers parents and distant resolvers would need to be
> able to fetch just these keys.

Just to clarify Olaf.
He is working on the problem to signal to parent (or anyone that 
trusts the current keys in a zone)
what keys belong in the DS set using only DNS. 

The constraints on his solution is that initial handshake has been
done out of band but further communication is done using DNS. 
He is to generate a solution is for the normal rollover case.
The solution does not have to cover ALL emergency cases.

> 
> Indicating the status of 'secure entry point' cannot be done with a
> key flag; toggling the flag would change the key id and that would be
> similar to a keyrollover.
> 
> The SEC RR could be used to indicate which keys in the keyset are used
> as secure entry points for a zone. This would be a purely
> administrative hint to resolver administrators or to parent zone
> administrators and would not influence the resolving process itself.
> 
> I find introducing a new RR for administrative purposes a little bit
> of an overkill but maybe the information could piggy-back on the SEC
> RR. 

This information belongs in the general concept of SEC RR. 
The name is maybe misleading as the data in there is more of a zone 
DNS configuration advertisement than security information,
so we may want to call this ZONE RR or DNS RR.

Everyone please think about what information can go in the this RR.

Send any suggestion/ideas to this list or directly to Ed as he has
agrred to be the clearing house for this discussion.

The plan is to get all ideas in soon and then summarize followed by
purging of ideas that do not belong in there and formulation
of concreate propoal. 

IFF DS requires SEC/ZONE RR we need to have a concreate propsal done 
in the next 3 weeks!!

	Olafur