Subject: [DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration

From: John Dickinson <[email-masked]>
Date: Wed, 16 Jun 2010 16:25:42 +0100

Hi, 

Sorry for the very late reply to this issue.

http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration

Paul asked for proper use of 5011 to be added to 4641bis. I agree, In fact could we go further and give implementation advice?

These are some thoughts on the subject, I know they cross into dnsext space but I think 4641bis might want to mention some of them.

1. One thing missing in RFC5011 is a mechanism to signal validator operators that RFC5011 key management is being performed.

2. There currently exist several ways in which validator operators can configure and manage their DNSSEC TAs. These mechanisms are different in each validator, according to the design of the implementors.

The current situation is that all known validators configure their trust anchors differently according to whether or not they are 5011 TA's or non-5011 TA's. There is no good reason for this. In addition, since RFC5011 provides no signalling there may be no way for validator operators to know where to configure the TA key.

4641bis could suggest to implementors that all TA's be configured in an identical manner in any given implementation. Note: 4641bis should say nothing about how the implementation should do this, just that all TA keys be treated equally in the configuration.

If the validator ever sees a revoke bit set on a key in a self signed RRSet it MUST stop trusting it, as described in RFC5011. If the validator never sees a revoked bit then as long as the authoritative operator is making the validator operator aware of key changes in some other way there will be no issues.

This should help ensure that keys are configured correctly.

2. There are also multiple ways in which the auth nameserver operators will manage key rollover.

Authoritative operators should free to decide if they want to manage their keys in a RFC5011 manner or not. RFC4641bis should place no restriction on authoritative servers.

(3. With RFC5011 we now have some confusion in the current RFCs about the status of the SEP bit.

RFC4034 describes the SEP bit as follows 
"Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behaviour during the signature validation process in any way based on the setting of this bit."

RFC4041
RFC4041 recommends "In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs"
This clearly alters RFC 4034 and gives some meaning to the SEP bit.

RFC5011
RFC5011 describes a method for securely managing key rollover via the use of the SEP bit and the addition of a revoke bit. This clearly redefines the original meaning of the SEP bit in RFC4034.

Could 4641bis or something mention

1. RFC3757 is not obsolete
2. RFC3757 is updated by RFC5011

The SEP bit is described in [RFC3757] and updated in RFC5011. However, it plays no part in the validation process. It may only be used in the automated key rollover process as described in RFC5011.)

John