Signalling DS support to resolvers

[Ólafur Guðmundsson <ogud@ogud.com>]

In the process of implementing DS I ran into the issue that there
is no easy way for a resolver to figure out if a zone uses RFC2535 semantics
or DS. I asked Dan Massey and Ed Lewis to write up short problem description
and how to apply a particular solution to the problem.

Please comment on which approach is more attractive, suggest other ones,
find cases where things will not work.

Once we have rough consensus, we will make a formal proposal will be taken
to namedroppers.

------
First Dan Massey for using KEY flags to signal DS support:

   Backwards compatability with SIG@child:

    In the ideal scenario, DS would be the only approach used for
    DNS key signing.  Unfortunately we have a legacy SIG@child approach
    from RFC 2535 and we have to consider backwards compatability.

    DS and SIG@child use conflicting mechanisms to signal a child's
    security status.  The possible contents of a delegation are:

       Delegation contains an NS set and DS set:
         child is secure using DS, not allowed with SIG@child.

       Delegation contains an NS set and NULL key:
         not allowed using DS, child is unsecure using SIG@child.

       Delegation contains only an NS set:
         child is unsecure using DS, child is secure using SIG@child

    The zone signer, the nameserver, and the resolver will all need to
    know whether the zone uses DS or SIG@child so the question is how
    do we signal this.

    The proposed answer is that the parent's key includes a flag to indicate
    DS or SIG@child.  By looking at the parent's key, you can determine
    if the parent uses SIG@child or DS to sign its children.

    There is one more complication.  Suppose the parent has multiple KEY
    records.  The flag must be set in any KEY record that is signed by
    the parent's parent (for SIG@child) or is stored in a DS record by
    the parent's parent.

------
Second Edward Lewis for the use of SEC RR to signal DS usage

Assuming the adoption of the DS RR, there is a need to maintain
compatibility between DS RR delegation semantics and RFC 2535/3090
delegation semantics.  The compatibility problem is complicated by an issue
regarding the absence of DS RR and KEY RR sets at a delegation.

According to the DS RR semantics, if no DS RR set exists at a delegation
point, the child zone is to be considered unsecured.  According to the RFC
2535/3090 semantics, the lack of a KEY RR set indicates that the child is
secured.  Because of this difference, a resolver cannot decide if the
absence of signed records at the child is the result of RFC 2535/3090
semantics or a dns-jacking of a secured child zone in a situation when DS
RR semantics are in use to indicate a secured child.

Because of this situation, there is a need for the parent to explicitly
state which set of semantics are in use, whether per-algorithm,
per-delegation, or for the entire zone.  Per-algorithm behaviour in DNS has
proven problematic in the past and will not be considered further.  A
discussion of the problems exists in RFC 3090.  Per-delegation indications
would have to rely on some existing mechanism to carry the indication,
which is not readily available.  From this point on, the discussion will
assume that an indication of whether a zone chooses DS RR semantics or RFC
2535/3090 semantics for all of its delegations is a requirement.

One of the means to indicate a zone's security semantics is to use the
oft-suggested but never fully defined SEC RR set.  The SEC RR set has been
a latent suggestion to relate security information about a zone.  There is
natural resistance to defining a new RR set, which is why the SEC RR set
has not been put forward.

This missive is intended to just state the case for re-consideration of the
SEC RR, not to define it nor discuss its merits in general.  The only
philosophical rationale that will be mentioned is that, like the DS RR set,
there has long been known a need to state information and up to know the
preference was to do this through inference.  As with the final acceptence
of the DS RR set, is may be time to capitulate to the definition of yet
another RR type to explicitly state information.

-----

Olafur with lots of help from Dan and Ed.