keys at apex (key points)

[Dan Massey <masseyd@isi.edu>]

Hi,

In attempt to summarize some key points...


Randy Bush stated the fundamental problem with:

  o what we have is a generic problem, how to go securely from a secured
    lookup in the dns to a wide set of secure APPLICATIONS on hosts.

Some questions which seem to apply here are:
     which application keys are appropriate for the DNS?
     how are these keys (or the pointers to these keys) stored in the DNS?
     what is needed to introduce a new application key?
     will DNS security be meaningful to these applications?

Solving this generic problem could make the entire keys at apex problem
irrelevant.

However, there is also second problem that relates to the definition and 
use of the KEY record.  This problem occurs if application keys are
stored in the DNS using the KEY record as described in RFC 2535.  

If this is done, the application keys can create some complications. 
Note that this problem is specific to the way the KEY record is used
and things like A records at the apex are not a problem for DNSSEC. 
The application keys only become a DNSSEC issue because they are stored 
in the same KEY record used for the DNSSEC zone keys.  These DNS zone keys 
are different from application keys in the following ways:.  

1)  DNS zone keys should be signed by the parent zone
    Application keys should be signed by the local zone

2)  Administering DNS zone keys invovles both the parent and child zones
    Administering application keys should involve only the local zone.

3)  DNS zone keys are used by resolvers to authenticate DNS data.
    Application keys must not be used by resolvers to authenticate DNS data

Since both types of keys go into the same KEY record, the rules for 
signing, administering, authenticating, and using a KEY record depend on 
the value in the protocol field.  There is the potential for unexpected 
and undesirable interactions between application keys and DNS zone keys. 
One example of this unexpected interaction is the keys at the apex problem.
In that problem, a KEY RR set contains both zone keys and application keys
and at best results in undesirable administrative issues..  It seems like 
the various solutions could prevent the keys at apex problem.  But are 
there other undesirable zone key/app key interactions that have yet 
to be encountered?

Another limitation is extremely large keysets.  One could easily imagine
a host with an SSH v1 RSA key, SSH v2 RSA and DSA keys, an RSA and DSA
IPSEC key, SSL keys, and so on.  This is large keyset.  In the worst case, 
put this large KEY set at the apex of zone.  A resolver that is simply 
trying to authenticat an A record would have to obtain this large keyset 
and sort through it to find the zone key.  In other words, even 
if you don't want application keys in the DNS and don't ever request them, 
they could still lie in your critical path for secure lookups.

Finally, I think that would be hard to blame the application designers for 
creating this large keysets and keys at the apex.  RFC 2535 has a KEY 
record with a protocol type for SSL and IPSEC.  An application designer 
reading this document might reasonably think the SSL or IPSEC key for 
host foo.com. should go in a foo.com. KEY record. (note this choice creates
both the keys at the apex and large keyset problem).  If we want to avoid
this, we need to provide application designers better directions.

I would like to suggest the following for the KEY record.  In the RFC 2535
revision, we leave the KEY format unchanged.  However, only the DNSSEC
protocol type will be explicitly defined.  For other protocol types, the 
revision will reference a second document that will discuss the proper use 
of application keys, the process for defining a new KEY protocol type, the 
risks to consider, and general directions for application designers who
might choose to use this.   This app key document could present Jakob's 
labeling approach or present any of the other alternatives or perhaps 
Randy could convince the group that no other protocol type should be 
allowed.  I would like to contribute to this document's discussion of the 
risks and things to avoid.  (I think others are better suited to stating
the correct solution).  The consideration of this document should reflect
the bigger picture issues raised by Randy.

Does this group feel that this would be an appropriate way to proceed? 

Dan