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: Roy Arends <[email-masked]>
Date: Tue, 16 Nov 2004 14:51:34 +0100 (CET)

> the new nsec. Draft is below.

I _love_ the name.

I don't like subtyping in DS records, why not a different type altogether.

I don't understand the need for 8 bits to distinguish between
noerror/no-data and nxdomain. 1035 specifies 4 bits, and 2671 specifies 8
more, so 12 in total. Furthermore, this implies you are able to sign
rcodes such as SERVFAIL or NOTAUTH or NOTIMP. What is the purpose of that
?

Why not use type=255 (ANY) to claim that no name exist (NXDOMAIN), while
any other type denies the type.

With that, you don't need a seperate BERT record to deny records.

You can just use SIG(qtype,qname,qclass), as I proposed some months ago
[see below]. If you really want to distinguish between these and static
signatures, use the subtyping hack for the signature algorithm.

Roy

----------------------------------
Date: Fri, 18 Jun 2004 12:50:25 +0200 (CEST)
From: Roy Arends <[email-masked]>
To: [email-masked]
Subject: continued: rrsig(qtype)

Hi,

A short write-up for working with dynamically generated RRSIGs, for those
who are interested.

notes:
(1) a signature for a non-existant name is generated as follows:

    sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=ANY

(2) a signature for a non-existant type is generated as follows:

    sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=QTYPE

(3) a signature for a expanded wildcard is generated as follows:

    sign(RRSIG_RDATA | RR(1) | RR(2) .. ) where RR(N) is the expanded
    wildcard.

The resolver never has to consider proof of wildcards. Just as with
vanilla DNS, a resolver is completely oblivious that this was a
dynamically signed synthesised record using wildcard expansion instead of
a pre-signed static record.

Operational detail:

It is recommended to use a unique zone-key per authoritative server. The
apex keyset might look as follows:

example. IN DNSKEY ksk 000 ; key-signing-key
example.    DNSKEY zsk 001 ; offline zsk for pre-signing.
example.    DNSKEY zsk 111 ; online zsk for dyn-signing by ns1.example.
example.    DNSKEY zsk 222 ; online zsk for dyn-signing by ns2.example.
example.    DNSKEY zsk 333 ; online zsk for dyn-signing by ns3.example.
example.    DNSKEY zsk 444 ; online zsk for dyn-signing by ns4.example.
example.    DNSKEY zsk 555 ; online zsk for dyn-signing by ns5.example.
example.    RRSIG DNSKEY 000
example.    RRSIG DNSKEY 001
example.    RRSIG DS 001 ; pregenerated denial for DS@child

Responses coming from ns3.example would have dynamically generated RRSIGs
by DNSKEY 333, etc.

The RRSIGs which are dynamically signed are marked with '!!' for clarity.
Note that it is not possible for the resolver/validator to notice the
difference between a dynamically signed and a pre-signed RRSIG (which is
good).

Denial for DS for unsigned delegations and at the apex is pregenerated.

In the response types below, only A.2 and A.3 have dynamically generated
RRSIG's. A.1 might have one if this is an expanded wildcard. The set below
covers the entire spectrum.

A.1 Answer

   A successful query to an authoritative server. No dynamically generated
   RRSIG in this response type, unless this in an expanded wildcard. In
   that case the (!!) marked RRSIG record is dynamic.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   x.w.example.        IN MX

   ;; Answer
   x.w.example.   3600 IN MX  1 xx.example.
   x.w.example.   3600 RRSIG  MX ..           (!!)

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS ..

   ;; Additional
   xx.example.    3600 IN A
   xx.example.    3600 RRSIG  A ..
   xx.example.    3600 AAAA   ..
   xx.example.    3600 RRSIG  AAAA
   ns1.example.   3600 IN A   ..
   ns1.example.   3600 RRSIG  A ..
   ns2.example.   3600 IN A   ..
   ns2.example.   3600 RRSIG  A ..

A.2 Name Error

   An authoritative name error.  The special RRSIG RR proves that the name
   does not exist.

   ;; Header: QR AA DO RCODE=3
   ;;
   ;; Question
   ml.example.         IN A

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ml.example.     600 RRSIG  ANY ...   (!!)

   ;; Additional
   ;; (empty)

A.3 No Data Error

   A "NODATA" response.  The special RRSIG RR proves that the name exists
   and that the requested RR type does not.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   ns1.example.        IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ns1.example.    600 RRSIG  MX ...   (!!)

   ;; Additional
   ;; (empty)

A.4.1 Referral to Unsigned Zone

   Referral to an unsigned zone.  The special RRSIG RR proves that no DS
   RR for this delegation exists in the parent zone. Not that the special RRSIG
   RR to signal absence of DS is not dynamically generated, hence no dynamic
   generation of RRSIG

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.b.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   b.example.     3600 IN NS  ns1.b.example.
   b.example.     3600 IN NS  ns2.b.example.
   b.example.     3600 RRSIG  DS ..

   ;; Additional
   ns1.b.example. 3600 IN A
   ns2.b.example. 3600 IN A

A.4.2 Referral to Signed Zone

   Referral to a signed zone.   The DS RR contains the data which the
   resolver will need to validate the corresponding DNSKEY RR in the
   child zone's apex.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.a.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   a.example.     3600 IN NS  ns1.a.example.
   a.example.     3600 IN NS  ns2.a.example.
   a.example.     3600 DS ...
   a.example.     3600 RRSIG  DS ...

   ;; Additional
   ns1.a.example. 3600 IN A
   ns2.a.example. 3600 IN A

Roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Nov 2004 09:52:18 -0500

>    this online signing method,  0 indicates DNSSECbis, 1 indicates this

What happens if there is a mix of DNSSECbis and "this method" keys in a DS set?

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

I would have been at the meeting, but I was busy raking the leaves from
the (now) empty non-terminals in my yard.

---

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

[On 16 Nov, @ 15:52, Edward wrote in "Re: MagicType draft ..."]
> What happens if there is a mix of DNSSECbis and "this method" keys in a DS 

I'm adding this to the "Loose Ends" section... :-)

But I guess the answer is, you mustn't do that. If we say you MUST NOT
do that, it would conflict with DNSSECbis.

This shows IMO that using the algorithms field of DS is a hack, and
maybe we should do what Roy suggested and use a new DS type for this
all together,

grtz Miek

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 16 Nov 2004 14:40:58 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Miek Gieben

> >
> > What happens if there is a mix of DNSSECbis and "this method"
> keys in a DS
> > set?
>

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.

> maybe we should do what Roy suggested and use a new DS type for this

Another option, but does that mean that there would be a DS RR and this new
type?  That would cause the same issues as 2 DS RRs.

Scott
PS - this post may be the result of a flu induced haze.

---

From: Andras Salamon <[email-masked]>
Date: Wed, 17 Nov 2004 22:41:45 +0200

>    longer the need to prove that the original QNAME does not exist.

I don't understand this text.

RFC 2535:

   In particular, when a non-existent name response is returned, an NXT
   must be returned showing that the exact name queried did not exist
   and, in general, one or more additional NXT's need to be returned to
   also prove that there wasn't a wildcard whose expansion should have
   been returned.

From wcard-clarify-00:

    When synthesizing a negative answer that is derived from a wild
    card, meaning that a wild card matched the QNAME (no exact match
    happened for QNAME) but that there is no match for QTYPE there, at
    most two negative answers are needed, possibly one.  As in 6.2.1,
    a proof that the exact match failed is needed.  A second proof is
    needed to show that the wild card domain name does not have the QTYPE.

Why does the online signing of wildcard records remove the need to prove
the original QNAME does not exist?

-- Andras Salamon                   [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Nov 2004 09:48:00 +1100

> -- Andras Salamon                   [email-masked]

	You are dealing with different threats and accepted risks.

	* Relay of wildcard proofs to different qnames.
	* Server compromise.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Nov 2004 21:18:29 -0500

>the original QNAME does not exist?

On-line signing of authenticated denials tailored to the query 
removes the need to worry about wildcards.  This is because the proof 
can be tied to the query.

E.g.,

If you want to prove that foo.example doesn't exist, you'd need:

                  bar.example. NSEC  example.
                               RRSIG NSEC
                  example.     NSEC  bar.example.
                               RRSIG NSEC
First shows that foo.example. isn't there, the latter that there's no 
wildcard.  The reason two are needed is that's how many it takes to 
show that all of the places to look as specified in RFC 
1034/4.3.2/step 3/part C.

If you tailor the answer, you'd only need:

                   fon.example. BERT   fop.example.
                                RRSIG  BERT .... by appropriate key ....

The difference is that that validator knows that the response was 
generated on the fly.  If there was a wildcard, that record would not 
have been generated, replaced by an answer (if appropriate).

For client-server protocols to work - you have to assume the other 
side is complying to the protocol.  DNSSEC doesn't protect against 
non-compliant implementations, it protects on modifications "in 
transit."  So, it's not important that the server 'prove' all its 
steps as it had to with NSEC - it's only important that the answer is 
signed by the holder of the secret needed.  Hopefully the secret is 
only available to the (authoritatively answering) server.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 22 Nov 2004 19:57:58 -0500 (EST)

> I don't like subtyping in DS records, why not a different

Another type that exists only at the parent side of a delegation?
And that will require special parent-finding code?  (Remeber the DS
lameness and grandparent problems from two years ago?)

This would add noticable new logic to resolvers, especially if we try
to allow both types to coexist at one delegation.  Imagine a referral
answer that includes a DS but not one of these new RR types -- would
you want the auth server to include the NSEC to prove that the new
type isn't there?  If not, resolvers will have to go issue another
query to every parent at every delegation, specifically looking for
those new types.

And there are interesting backwards compatibility issues: an auth
server that speaks DNSSECbis will only include an NSEC record in a
referral (proving lack of other types at a delegation) when there's no
DS.  What's a poor resolver that groks this new type to do?  Go pound
that parent with more queries looking for the new type?

As much as I'm a fan of changing type codes, using a new DS type
scares me.

-- Sam

---

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: Samuel Weiler <[email-masked]>
Date: Mon, 22 Nov 2004 20:38:06 -0500 (EST)

> > What happens if there is a mix of DNSSECbis and "this method" keys in a DS
...
> do that, it would conflict with DNSSECbis.

I don't see the conflict with DNSSECbis.  A co-existence restriction
makes it difficult if not impossible to change between the
non-existence proof mechanisms without going through an unsecure
state, which would not satisfy an identified requirement[1].  Other
than that, I think the restriction would be fine to add, even if it
means a change to DNSSECbis.

-- Sam

[1]  This may or may not be a problem.  Our requirements document
doesn't tell us whether any of those who are unwilling to do on-line
signing (the epsilon approach or the MagicType approach) also need to
be able to transition from enumerable NSEC to something new without
going unsecure.  I'd still like to see that analysis.  For
clarification:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01994.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01823.html