Subject: MagicType draft

From: Miek Gieben <[email-masked]>
Date: Tue, 16 Nov 2004 10:07:16 +0100

Hello,

this is the draft explaining the MagicType option we have for
the new nsec. Draft is below.

DNSEXT                                                         R. Gieben
Internet-Draft                                                NLnet Labs
Expires: May 17, 2005                                  November 16, 2004

           Online Signing of Negative and Wildcard Responses
                   draft-gieben-bert-response-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This draft contains a number of loose ends and does not include any
   text on any (known) corner cases.  Its primary goal is to document
   the choices the DNSEXT working group has on the subject of fixing the
   NSEC enumeration in DNSSEC.  If at any point in time the working
   group feels this idea needs further work, this draft will be updated.

   DNSSECbis [RFC LIST] allow for zone enumeration by walking NSEC
   chains.  It also has a large impact on the zone size at the initial

Gieben                    Expires May 17, 2005                  [Page 1]

Internet-Draft            BERT Resource Record             November 2004

   deployment stage.  This draft proposes a method to address these
   issues by the use of online signing of negative and wildcard
   responses.

1.  Method

   To achieve the goal of online signing we will introduce the Basic
   Error Response Type (BERT) meta record (type = TBD).  We will sign
   the BERT meta record to indicate the type of negative response and
   the type(s) covered.

   The BERT record contains two fields.  A Rcode field, 8 bits long.
   Which can hold two values: "No Error" or "Name Error" [RFC 1034/35].
   The second is the type covered field, which is 16 bits.

   Rcode field:
      No Error:  A No Error rcode indicates that the <QNAME, QCLASS>
         tuple exists in the DNS but the QTYPE does not.
      Name Error:  A Name Error rcode indicates that the <QNAME, QCLASS>
         tuple does not exist.

   Type covered field:  This is normally the QTYPE value from the
      original query but MUST be set to `*` (255) for Name Error
      response and No Data responses from empty non-terminal nodes.

   This record is signed with online DNSKEY(s) by the authoritative
   server for the zone with a TTL derived from the SOA MINIMUM field.

   The resulting RRSIG is included in the response to the client.
   Multiple signatures are allowed.

   Since this method requires online signing there is no longer the need
   to special case wildcard records.  These will now be signed on the
   fly.  This in turn simplifies negative responses, as there is no
   longer the need to prove that the original QNAME does not exist.

2.  DNSKEY Considerations

   A zone can choose whether to share a common key for online signing or
   each authoritative server can have its own zone signing key or use a
   mixture.  The key signing key should not be shared amongst the
   servers.  Note: all public keys used to perform online signing MUST
   be in the DNSKEY RRset.

   [Loose end]

Gieben                    Expires May 17, 2005                  [Page 2]

Internet-Draft            BERT Resource Record             November 2004

3.  RRSIG Considerations

   Signatures generated by this method can be cached by the
   authoritative server as a aid against DoS attacks or broken clients.

   [Loose end]

4.  Interaction with DNSSECbis

   To permit this online signing method to interact with DNSSECbis we
   will take the high bit from the algorithm field of the DS record and
   use it to indicate whether the child zone is signed with DNSSECbis or
   this online signing method,  0 indicates DNSSECbis, 1 indicates this
   method.

   [Editors Note: Needs more work, Loose End] Islands of trust need to
   know a priori which DNSSEC method is being used.  They can tell this
   by looking at the ALG field of the DS records.

5.  Security

   Zones signed with this online signing method will appear to be
   insecure to DNSSECbis servers.  The DNSSECbis resolvers will not
   understand the algorithm.

   Then there are the usual risks associated with keeping keys online.

   One of the operational impacts of using online signing is that a
   primary server feeding a couple of slave servers is less easily
   setup.  Because an administrators is faced with the problem of how to
   distribute the private keys(s) used to generate the BERT RRs.

   The DS BERT records can either be generated on the fly or be
   precomputed.

6.  Acknowledgements

7.  Loose Ends

   Some of the loose ends not covered in this draft are, SERVFAIL
   reponses, DoS attacks on nameservers.  Key consideration for slave
   servers.  General key usage issues; how long to use, what length.
   RRSIG considerations.  Empty non terminals.  Rcode of the BERT
   message itself.  In which section should these RR be placed.

   If the working group decides so, these loose ends will be tied up.

Gieben                    Expires May 17, 2005                  [Page 3]

Internet-Draft            BERT Resource Record             November 2004

Author's Address

   Miek Gieben
   NLnet Labs
   Kruislaan 419
   Amsterdam  1098 VA
   The Netherlands

   EMail: [email-masked]
   URI:   http://www.nlnetlabs.nl

Gieben                    Expires May 17, 2005                  [Page 4]

Internet-Draft            BERT Resource Record             November 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Gieben                    Expires May 17, 2005                  [Page 5]


--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 22 Nov 2004 20:16:01 -0500 (EST)

On Tue, 16 Nov 2004, Scott Rose wrote:

> Really?  I would think that it would almost work.  Wouldn't it be
> the same as having 2 DS RRs, and one having an unknown algorithm
> type?  A DNSSECbis validator would still be able to validate
> positive responses, it's negative responses that would cause some
> errors (unknown algorithms code).  Depending on local policy, the
> validator might resend the query in an attempt to get an RRSIG it
> can understand.

What does the auth server do when it's advertising (via DS/DS') that
both kinds of non-existence proofs are available?  On name errors,
return both a BERT RR and an NSEC RR (proving that the BERT RR doesn't
exist)?  It doesn't know whether the resolver asking the query wants
NSEC-type proofs or BERT-type proofs -- it has to provide an answer
that works for both.  And that answer has to be completely
backwards-compatible with DNSSECbis resolvers.

I think the answer to Ed's question of "What happens if there is a mix
of DNSSECbis and 'this method' keys in a DS set" is: the world ends.
Depending on the resolver's mood, do something either kind and gentle
(treat the zone as unsigned), colorful (treat the zone as not
existing), or punitive (see draft-ietf-dnsop-bad-dns-res-03.txt, now
in WGLC, for creative ideas).

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 23 Nov 2004 12:36:28 -0500

> -----Original Message-----
> From: Samuel Weiler [mailto:[email-masked]]
>
I don't know, kind of why I asked.  If I read that correctly, you believe
that magic type and DNSSECbis can't co-exist in a zone?  I think that might
be the case as well.  My comment was that it would be nice to have a way for
a DNSSECbis resolver to get/validate positive DNSSEC responses from a zone
that does magic type.  If we use an algorithm code in the DS, the resolver
will make the zone as "unsecure" (I hope) and continue, but be unable to
verify even if the response was positive and uses a RRSIG algorithm the
validator understands normally.

> in WGLC, for creative ideas).

Scott

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Nov 2004 14:42:30 -0500

Why can't a zone that purports to do both in the DS RRSet do both?

Why can't both a BERT RRSet and a NSEC RRSet be returned?

(Will a non-BERT RR verifier choke on the presence of an unknown type 
in the authority section?)

What would the size of a message containing both be (order of magnitude)?

Always keep in mind that DNSSEC is for the benefit of the resolver - 
doing anything punitive would be shooting itself in the bootstrap 
loader.

IMHO - if someone gave me a package which indicated multiple ways to 
verify it's authenticity and included all of the credentials for each 
of the multiple paths, you can bet that I would try the easiest 
verification first, trying successively harder ones until I succeed 
or run out of options.

The last thing I'd want to do is throw away an accepted package - 
that's why I'd progress through them all.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

I think my jabber client and SMS phone are talking about me behind my back.