Subject: Re: MagicType draft

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

On Tue, 16 Nov 2004, Miek Gieben wrote:

> Hello,
>
> this is the draft explaining the MagicType option we have for
> 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

--
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: Edward Lewis <[email-masked]>
Date: Tue, 16 Nov 2004 09:52:18 -0500

At 4:07 -0500 11/16/04, Miek Gieben wrote:
>            Online Signing of Negative and Wildcard Responses
>                    draft-gieben-bert-response-00.txt

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

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

On Tue, Nov 16, 2004 at 10:07:16AM +0100, Miek Gieben wrote:
>    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.

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: 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: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