Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

[Roy Arends <Roy.Arends@nominum.com>]

All,

You might have seen a few a messages on the list from my hand, which might
seem hard to interpret. The ideas mentioned in the second part of this
mail is what I wanted to make share. All ideas are a result of numerous
discussions with Jakob Schlyter, Mats Dufberg, Scott Rose, Dan Massey and
a visit at Verising-GRS Applied Research in Dulles, VA (Mark Kosters and
David Macka).

The following does however not reflect their opinion. Some may [not] agree
with [some] ideas, some may not even agree with this statement :-)

This is how I understand the opt-in draft:

  Take the following zone.

  $ORIGIN test.
  @  SOA  rdata        ; the apex is signed
  @  SIG  (SOA)        ;
  @  NXT  a  SOA       ;
  @  SIG  (NXT)        ;

  a  NS   ns.a         ; this delegation RRset is signed
  a  SIG  (NS)         ;
  a  DS   rdata        ; DS or KEY
  a  SIG  (DS)         ;
  a  NXT  d SIG NXT DS ; DS or KEY
  a  SIG  (NXT)        ;

  b  NS   ns.b         ; this delegation RRset is not signed

  d  MX   rdata        ; this RRset is signed.
  d  SIG  (MX)         ;
  d  NXT  @ MX SIG NXT ;
  d  SIG  (NXT)        ;

  e  MX   rdata        ; this RRset is not signed.

Possible answers:

1) query for a.test. A
   response from test. nameserver: (referral)
   RCODE    : NOERROR
   ANSWER   : -------
   AUTHORITY: a.test. NS  ns.a.test.
              a.test. DS  rdata
	      a.test. SIG (DS)

2) query for a.test. NS
   response from test. nameserver: (referral)
   RCODE    : NOERROR
   ANSWER   : a.test. NS  ns.a.test.
   AUTHORITY: a.test. DS  rdata
              a.test. SIG (DS)

3) query for b.test. NS
   response from test. nameserver: (referral)
   RCODE    : NOERROR
   ANSWER   : b.test. NS  ns.b.test.
   AUTHORITY: a.test. NXT d.test. SIG NXT DS
              a.test. SIG (NXT)

4) query for c.test. NS
   response from test. nameserver:
   RCODE    : NXDOMAIN
   ANSWER   : --------
   AUTHORITY: b.test. NXT e.test. SIG NXT DS
              b.test. SIG (NXT)
              test. SOA rdata
              test. SIG (SOA)

5) query for d.test. MX
   response from test. nameserver: (authoritative)
   RCODE    : NOERROR
   ANSWER   : d.test. MX  rdata
              d.test. SIG (MX)
   AUTHORITY: ---------

6) query for d.test. A
   response from test. nameserver:
   RCODE    : NOERROR
   ANSWER   : -------
   AUTHORITY: d.test. NXT test. MX SIG NXT
              d.test. SIG (NXT)

7) query for e.test. MX
   response from test. nameserver: (authoritative)
   RCODE    : NOERROR
   ANSWER   : e.test. MX  rdata
   AUTHORITY: d.test. NXT test. MX SIG NXT
              d.test. SIG (NXT)

  In all queries DO bit is set. The additional section is not specified
  here.

  1 and 2 indicate signed delegations.
  3 indicates an unsigned delegation.
  4 is of "NXDOMAIN". neither label nor type does exist in this zone.
  5 is an authoritative response with a signed RRset in ANSWER.
  6 is of "NO DATA".  Label exists, but type does not exist in this zone.
  7 is an authoritative response with an unsigned RRset in ANSWER.

  A caching resolver does not give response 1,2 and 3, and has no AA
  bit set on response 5 and 7.

  Though query responses might be spoofed: All RRsets with accompanied SIG
  are verifiably secure. All RCODEs, unsigned RRsets and header bits
  (aa,tc,rd,ra,cd,ad) are not signed and can be spoofed (use tsig/sig(0)
  to circumvent this).

Conclusion:
-----------
  If the receiving secure resolver does not know whether the zone was
  partially signed or fully signed, while a zone was fully signed (aka
  rfc2535-style), responses like 3 and 7 are spoofed. It is necessary for
  the resolver to know how to interpret the NXT record.

Please correct me if any of the above is wrong.

============================================================================

Now for the ideas:
------------------

  As said it is necessary for a secure resolver to know how to interpret
  the NXT record: This can be done on a per record basis if this is
  signalled with the NXT record, say by setting some new defined RR-type
  bit, a response  can never be spoofed.

  (In what follows I refer to the OPTIN RR-bit as "OPT")

  The NXT records in the zone above would be:

  $ORIGIN test.

  @ NXT a SOA              ; between @ and a are no records.
  a NXT d SIG NXT DS OPT   ; between a and d are no records signed.
  d NXT @ MX SIG NXT OPT   ; between d and @ are no records signed.

  (note, setting OPT on the first NXT is optional. There is no
  RRset between @ and a, so there is also no signed RRset between @ and
  a)

  query-responses 3 and 7 must have the OPT indication. If not, they are
  spoofed.

  Indication on a per record basis can not be done with either a bit in
  the key, nor in a special SEC record.

In general:
-----------
  One of the 2 below is mandatory in a signed zone:

  A NXT+OPT is created for a label when there is some signed RRset by
  that label. It points to the next signed label.

  A NXT w/o OPT is created whenever there is some RRset for that label.
  It points to the next label.

  The APEX is allways signed in a secure zone, thus the APEX has always a
  NXT.

Why and Who:
------------

  The really strict zone administrator signs the whole zone and uses NXT
  w/o OPT (fully rfc2535-style).

  The very large (.com) zone administrator might want to sign just the
  apex, and some delegations, sets the OPT on every NXT. (fully
  optin-style)

  For the fine-grained security-savvy administrator, that does not need
  to sign delegations, its TXT,LOC,HINFO records, but wants to sign some
  A records, and be sure that nothing is spoofed between the signed A
  record www.test and zzz.test, creates NXT w/o OPT over "www.test. NXT
  zzz.test.", and uses NXT+OPT at other signed labels.

How:
----
  (partially signed zone)
  Take a zone-file, flush the records you want to sign in a temp file,
  sort and sign the temp file with NXT+OPT and concatenate it with the
  zone-file again.

  (fully signed zone)
  Sort and sign the zone file with NXT w/o OPT.

  (partially signed zone + denial of existence between some RRsets)
  Take partially signed zone, add (or replace) a NXT w/o OPT + SIG(NXT)
  for the part you want to deny existence for.

I hope this computes.

Regards,

Roy Arends
Nominum