[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Domain Name System Security WG                           Edward Lewis
INTERNET DRAFT                                           TIS Labs
<draft-lewis-dnskey-referral-00.txt>                     Jerry Scharff
                                                         John Gilmore

                                                         June 1, 1998

                             The Zone Referral Key

0.0 Status of this Memo

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its
    areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    ``work in progress.''

    To view the entire list of current Internet-Drafts, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    ftp.nordu.net (Northen Europe), ftp.nis.garr.it (Sourthern
    Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
    Coast), or ftp.isi.edu (US West Coast).

    This Internet Draft expires on 1 December 1998.

    Please send comments to the authors and dns-security@tis.com.

1.0 Abstract

    A new type of key is defined to address the problems of
    performance in large delegeted zones and issues of liability of
    registrars with regards to the storing of public keys belonging
    to zone cuts.  This new key type also brings DNSSEC more in line
    with the DNS treatment of zone cuts and speeds recovery in
    handling key exposure.

    The new type of key is a referral record that is stored, signed,
    at the parent zone's place for the delegation point.  A resolver
    receiving this record is being informed that there are genuine
    public keys at the child's authoritative name servers.  The
    parent no longer needs to store the child's public keys locally.

2.0 Introduction

    There are a number of different reasons for the proposal of this
    new key type.  Reasons include:
     o the performance impact the current proposal has on name servers
     o the problem of updating a widely delegated parent zone on demand

Expires December 1, 1998                                      [Page  1]
Internet Draft                                                 June 1, 1998

     o statements in RFC 2181 on authoritative data at delegations
     o perceived liability of the operator of a name server or registry

    To address these issues, which are expanded upon below, a new
    key type is proposed - a "zone key referral" - to join the user
    key, host key, and zone key types defined in ietf-draft-dnssec-

2.1 Performance Issues

    A sample zone will be used to illustrate the problem.  The
    example will part from reality mostly in the length of zone
    names, which changes the size of the owner and resource record
    data fields.

        # $ORIGIN test.
        # @         IN SOA   <SOA data>
        #           IN SIG   SOA <by test.>
        #           IN KEY   <1024 bit zone key>
        #           IN SIG   KEY <by test.>
        #           IN SIG   KEY <by .>
        #           IN NS    ns.test.
        #           IN SIG   NS <by test.>
        #           IN NXT   my-org.test. NS SOA SIG KEY NXT
        #           IN SIG   NXT <by test.>
        # my-org    IN KEY   <1024 bit zone key>
        #           IN KEY   <1024 bit zone key>
        #           IN SIG   KEY <by test.>
        #           IN NS    ns1.my-org.test.
        #           IN NS    ns2.my-org.test.
        #           IN NXT   them.test. NS SIG KEY NXT
        #           IN SIG   NXT <by test.>
        # them      IN KEY   0xC100 3 1
        #           IN SIG   KEY <by test.>
        #           IN NS    ns1.them.test.
        #           IN NS    ns2.them.test.
        #           IN NXT   test. NS SIG KEY NXT
        #           IN SIG   NXT <by test.>

    In this zone file fragment, "my-org" is a delegation point of
    interest with two registered public keys.  Presumably, one key
    is for signatures generated currently and the other is for still
    living and valid but older signatures.  "them" is another
    delegation point, with a NULL key. This signifies that this zone
    is unsecured.

    To analyze the performance impact of the storing of keys, the
    number of bytes used to represent the RRs in the procotol format
    is used.  The actual number of bytes stored will likely be
    higher, accounting for data structure overhead and alignment.
    The actual number of bytes transferred will be lower due to DNS
    name compression.

Expires December 1, 1998                                      [Page  2]
Internet Draft                                                 June 1, 1998

    The number of bytes for my-org's two 1024-bit keys, two NS
    records, NXT and the associated signatures is 526.  The bytes
    needed for them (with the NULL key) is 346.  Currently, there
    are close to 2 million entries in com., so if we take my-org as
    a typical domain, over 1GB on memory will be needed for com.

    The zone keys used in the example are set to 1024 bits.  This
    number may range from as low as 512 bits upwards to over 3000
    bits.  To scale the above numbers to a different key size,
    multiply the difference in key sizes by 4 for my-org and by 2
    for them, and adjust the numbers accordingly.

    The increased size of the data held for the zone cuts will have
    two impacts at the transport and below layers.  Bandwidth beyond
    that currently needed will be used to carry the KEY records.
    The inclusion of all of the child's keys will also push DNS over
    the UDP size limit and start using TCP - which could cause
    critical problems for current heavily used name servers, like
    the roots.

    Another impact, not illustrated by the example, is the frequency
    of updates.  If each time a public key for my-org is added or
    deleted, the SOA serial number will have to increase, and the
    SOA signed again.  If an average zone changes its keys(s) once
    per month, there will be on average 45 updates per minute in a
    zone of 2 million delegations.

2.2 Security Incident Recovery (w/ respect to keys only)

    Once a zone administrator is alerted that any key's private
    counterpart has been discovered (exposed), the first action to
    be taken is to stop advertising the public key in DNS.  This
    doesn't end the availability of the key - it will be residing in
    caches - but is the closest action resembling revokation
    available in DNS.

    Stopping the advertisement in the zone's name servers is as
    quick as altering the master file and restarting the name
    server.  Having to do this in two places will will only delay
    the time until the recovery is complete.

    For example, a registrar of a top level domain has decided to
    update its zone only on Mondays and Fridays due to the size of
    the zone.  A customer/delegatee is the victim of a break in, in
    which one of the items taken is the file of private keys used to
    sign DNS data. If this occurs on a Tuesday, the thief has until
    Friday to use the keys before they disappear from the DNS, even
    if the child stops publishing them immediately.

    If the public key set is in the parent zone, and the parent zone
    is not able to make the change quickly, the public key cannot be
    revoked quickly.  If the parent only refers to there being a key
    at the child zone, then the child has the agility to change the

Expires December 1, 1998                                      [Page  3]
Internet Draft                                                 June 1, 1998

    keys - even issue a NULL key, which will force all signatures in
    the zone to become suspect.

2.3 DNS Clarifications

    RFC 2181, section 6, clarifies the status of data appearing at a
    zone cut.  Data at a zone cut is served authoritatively from the
    servers listed in the NS set present at the zone cut.  The data
    is not (necessarily) served authoritatively from the parent.
    (The exception is in servers handling both the parent and child

    Section 6 also mentions that there are two exceptions created by
    DNSSEC, the NXT single record set and the KEY set.  This
    proposal addresses the exception relating to the KEY set,
    limiting its severity (but falling short of removing it
    altogether).  By limiting the exception, we will be simplifying

2.4 Liability

    Liability is a legal concept, so it is not wise to attempt an
    engineering solution to it.  However, the perceived liability
    incurred in using DNSSEC by registrars may prevent the adoption
    of DNSSEC.  Hence DNSSEC should be engineered in such a away to
    address the concern.

    One source of liability is the notion that by advertising a
    public key for a child zone, a parent zone is providing a
    service of security.  With that comes responsibility.  By having
    the parent merely indicate that a child has a key (or has no
    key), the parent is providing less in the way of security.  If
    the parent is wrong, the potential loss is less.  Instead of
    falsely authenticated data, configuration errors will be
    apparent to the resolving client.

3.0 The Proposal

    The proposal is to introduce a new key type which indicates
    whether the delegated zone is running secured or not.  Running
    secured is either a zone signed with at least one key, an
    experimental zone, or a zone with only NULL keys published.

    The Zone Referral Key will resemble the NULL key in syntax.
    There will be a flags field, an algorithm field, and a protocol
    field, but no public key material.  The Referral Key is signed
    by the parent zone, as was the public key set in RFC 2065.
    There is only one Referral Key RR present.

Expires December 1, 1998                                      [Page  4]
Internet Draft                                                 June 1, 1998

    The Referral Key flags field will have the following values:
     Field      Bit(s)     Value      Meaning

      A/C        0- 1      0b01       indicates a key will be found
                           0b11       indicates a key will not be found
                           0b?0       error (referral cannot encrypt)
      XT          2        0          no extended flags are needed
      Z          4- 5      0          must be zero for all keys
      NAMTYP     6- 7      0b11       this is a referral to a zone key
      Z          8-11      0          must be zero for all keys
      SIG       12-15      0          must be zero for a referral key

    The legal values of the flags field are (in summary):

      Hex Value    Indicates
      0x4300       The delegation has a key record set
      0xC300       The delegation has no key record

    Other values are not valid for Referral Keys (but may be valid
    for other keys).

    The Protocol field must be set to 3, the DNSSEC protocol value.

    The Algorithm field must be set to 0.

3.1 Example

    The Referral key for my-org.test. and them.test. would appear as
    the following in the zone master file:

          my-org.test. IN KEY   0x4300 3 0
          them.test.   IN KEY   0xC300 3 0

    In the example introduced earlier, the master file would change
    to the following.

        # $ORIGIN test.
        # @         IN SOA   <SOA data>
        #           IN SIG   SOA <by test.>
        #           IN KEY   <1024 bit zone key>
        #           IN SIG   KEY <by test.>
        #           IN SIG   KEY <by .>
        #           IN NS    ns.test.
        #           IN SIG   NS <by test.>
        #           IN NXT   my-org.test. NS SOA SIG KEY NXT
        #           IN SIG   NXT <by test.>
        # my-org    IN KEY   0x4300 3 0
        #           IN SIG   KEY <by test.>
        #           IN NS    ns1.my-org.test.
        #           IN NS    ns2.my-org.test.
        #           IN NXT   them.test. NS SIG KEY NXT
        #           IN SIG   NXT <by test.>

Expires December 1, 1998                                      [Page  5]
Internet Draft                                                 June 1, 1998

        # them      IN KEY   0xC300 3 1
        #           IN SIG   KEY <by test.>
        #           IN NS    ns1.them.test.
        #           IN NS    ns2.them.test.
        #           IN NXT   test. NS SIG KEY NXT
        #           IN SIG   NXT <by test.>

4.0 Analysis

    By removing the public keys from the parent's master file, the
    parent is no longer a road block during an emergency removal of
    keys.  A parent zone is unchanged as a zone changes from NULL
    keys to experimental keys to fully signed.  The parent is also
    not providing a security service, other than to authentically
    claim the existence of a KEY record set - akin to the "hints" of
    the name servers.

    The change also improves the prospect for performance.  The need
    for multiple KEY RR's, each one on the order of 100 bytes, is
    removed and replaced by a single KEY RR of the order of 25
    bytes.  Saving bytes reduces the need to use TCP to avoid
    truncated responses.  Also, the need for updating the zone drops
    - no longer will there be updates for each key change.

    As far as the statements by RFC 2181 conerning authority levels,
    the Referral Key is not authortative and would be superseeded by
    a verified set of the real zone keys.  The only caveat is that
    once the verified set of keys expire (assuming the parent has to
    learn the keys from another server), the Referal Key must
    reappear.  This is an example of what has been labelled "mount-
    like semantics."

    [No reference for mount-like semantics has yet been found.]

    The last point is important.  This requires the "mount-like
    semantics" that have been discussed for the BIND name servers.
    Once hints are overridden by learned, authorititative and
    verified data, the hints are not discarded.  Hints in this state
    are stored and become visible when the learned data expires.

5.0 IANA Considerations

    Other than using a new value in the flags field of the KEY RR,
    no new number assignments are needed.  The flags field is not
    under the control of IANA as of yet.  There are no requirements
    placed on IANA by this draft.

6.0 Security Considerations

    There has been some debate about whether the Referral key should
    be treated as a hint - just like the NS records.  If so, then
    there is no need to sign the Referral Key, and an unsigned
    (hence non-authenticated) security record is of little value.
    So, is the Referral Key even needed?

Expires December 1, 1998                                      [Page  6]
Internet Draft                                                 June 1, 1998

    Authentication in DNSSEC is done from the data "back" towards a
    trusted point - e.g., "up" to the root.  Since the
    authentication is done by going repeatedly from child to parent,
    why bother having the parent indicate the status of the child?

    The answer is in the scenario in which a resolver somewhere has
    obtained data which fails the verification process.  Perhaps the
    signature is wrong, a key in the chain of trust is unavailable,
    the set should have had a signature, but none is found (or vice
    versa), or the trail of signed-by names is not acceptable.  In
    this case, the resolver needs to find the authoritative zone,
    its status and its name server set.

    If a zone is being attacked by a masquerader, and parents do not
    make any statements about the security of child zones, then an
    easy and successfull attack may occur.  An attacker only needs
    to supply either fake name server records or glue records to
    redirect queries.

    While this attack will not be stopped as far as denial of
    service, the masquerader can be stopped from being accepted as
    an authoritative source if the parent of the zone claims the
    child is secure and signs the public keys of the true child and
    not the masquerader.

    The masquerader cannot successfully claim that the zone is
    unsigned, because it must have a zone key signed by the parent.
    NULL or not, the key would not be trusted by the resolver,
    assuming the parent has not also been duped.  The resolver,
    sensing this, should report an error or security incident, and
    not accept data.

7.0 Author's addresses

Edward Lewis                   Jerry Scharf                   John Gilmore
<lewis@tis.com>              <scharf@vix.com>               <gnu@toad.com>

Expires December 1, 1998                                      [Page  7]