Subject: this week in dnssec, 10 years ago.

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 23:24:29 +0200

Forwarded message 2 out of 2 (there where problems posting)

> From: Paul Vixie <[email-masked]>
> Date: May 19, 2004 6:49:40 PM CEST
> To: [email-masked]
> Subject: this week in dnssec, 10 years ago.
>
>
>> ...  But designing DNSSEC to not introduce new realistic attack 
>> vectors,
>> compared to vanilla DNS, has always appeared sensible to me.  ...
>
> simon picked an interesting point in time to make his concerns widely 
> known
> and propose a significant protocol/system design change to address 
> them.  do
> we have some kind of carrier wave / harmonic underlying this whole 
> project?
>
>> The alternatives to NSEC do reduce the attack vector into an offline
>> dictionary attack, which I believe is an acceptable risk. ...
>
> this week in dnssec, 10 years ago, donald eastlake proposed "NX" which 
> became
> "NXT" and then "NSEC".  see below.  how much longer do we want to work 
> on
> this?  i was thinking we'd begin early deployment work this month or 
> next...
>
> re:
>
> --------
>
> To: [email-masked]
> Subject: Thought on non-existant and wildcarded names
> Date: Mon, 09 May 94 14:55:42 -0400
> From: "Donald E. Eastlake 3rd (Beast)" <[email-masked]>
> X-Mts: smtp
>
> This is what I came up with and am thinking of merging into the next 
> draft:
> 
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>
>
>
>
>                 Domain Name Protocol Security Extensions
>
>
>
> W. Special Handling of Wildcard Matches and Non-existence
>
> DNS security provides the means for establishing integrity and data
> origin authenticity.  However, this applies only to actual RRs in a
> secured zone.  There are two places where would be insufficient
> without some additional steps.  The first case is securely indicating
> the absence of data.  The other is the that of wildcard RRs.  Wildcard
> RRs have node names whose first label is an asterisk ("*").  These act
> as instructions for synthesizing RRs not actually present.
>
> Since there are an enormous number of possible DNS names, it is
> impossible to create and sign separate existence RRs for all possible
> wildcard matches or denial RRs for all possible queries for
> non-existent data.  These are handled securely as described below.
>
> The following example zone is used in this section:
>
>      FOO. IN     SOA  QQ.FOO.  admin.QQ.FOO.
>                       (   60   ; serial
>                           7200  ; refresh
>                           600  ; retry
>                           1000000  ; expire
>                           60  ; minimum
>                       )
>                  NS      QQ
>                  NS      X.BAR
>                  MX  10  A1
>                  MX  99  QQ
>
>      A1          A       192.0.2.252
>                  A       192.245.52.250
>                  MX  10  A1
>                  MX  99  QQ
>
>      X.BAR       A       192.0.2.253
>                  A       192.245.52.249
>                  MX  10  X.BAR
>                  MX  80  Y.Z.BAR
>
>      Y.Z.BAR     A       192.245.52.248
>                  MX  10  Y.Z.BAR
>                  MX  80  Z.BAR
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 1]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>      *.BAR       MX  10  Y.Z.BAR
>                  MX  80  X.BAR
>
>      QQ          A       192.0.2.254
>                  MX  10  QQ
>                  MX  50  A1
>
>
>
> W.1 Wildcard RR Matches
>
> The Domain Name System contains a provision for RRs that match any name
> below a point in the name tree unless a more specific name matches.
> (See section 4.3.3 in RFC 1034.)  For example, in zone FOO, there is an
> RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO 
> and
> Y.Z.BAR.FOO.  The wildcard RRs with name *.BAR.FOO can be though of as
> instructions for synthesizing RRs with matching names and the same
> class, type, TTL, and RDATA, when a matching query arrives.
>
> If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will
> match the wildcard RR and not any of the more specific RRs. So a
> response will be made with the queried name (Z.BAR.FOO) substituted for
> the wildcard name (*.BAR.FOO).  On the other hand, a query for 
> X.BAR.FOO
> or Z.BAR.FOO or anything below them will ignore the wildcard and either
> respond with the specific RR or a non-existent name response.  Queries
> for xx.FOO, where xx is any label but BAR, will be unaffected by the
> wildcard.
>
> A wildcard is frequently used for such purposes as causing mail to a
> large class of name to be sent to a particular set of mail gateways by
> using wildcard MX RRs.
>
> Wildcard RRs are signed by SIG RRs with the same wildcard name and the
> signature is based on the wildcard name.  To make it possible to verify
> the signature, the SIG RR has a LABELS field which gives the number of
> actual labels in its name, above the wildcard *, if there is one, not
> counting the null label for root.  If the actual number of labels
> present in the RR name equals the LABELS field, then no wildcard is
> involved.  If the actual number of labels present is larger, then an *
> can be temporarily substituted for the synthesized part of the name to
> verify the signature.
>
> If a wildcard RR has been supressed because it appears inside a SIG on 
> a
> request for a security aware resolver to a security aware server, the
> resolver has to do the wildcard expansion.
>
>
>
>
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 2]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> W.2 Non-existent Types
>
> When a secure query is made for a name and class that exist is a zone,
> but for an RR type that does not exist, there needs to be a secure way
> to know that the type does not exist.  This can be determined by
> retrieving and examining all the SIG RRs.  All types will be indicated
> within the SIGs and the partial RR set signets in the SIGs can be used
> to assure that a complete set of SIGs has been retrieved.
>
> Thus a query from a security aware resolver for a name that exists for
> some RR in a zone but not as the owner of any RR of the requested type
> should be answered by a security aware server with the usual error but
> with all the SIGs for that name as additional information.
>
>
>
> W.3 Nonexistent Names
>
> The nonexistence of a name in a zone is indicates by the NX resource RR
> for a name interval containing the nonexistent name.  An NX RR is
> returned in the additional information section, along with the error, 
> if
> the client is security aware.  NX RRs can also be returned if an
> explicit query is made for the NX type.
>
> The existence of NX records means that any query for any name to a
> security aware server serving a secure zone should result in an reply
> containing at least one signed RR.
>
>
>
> W.3.1 The NX Resource Record
>
> The NX resource record is used to securely indicate that no RRs with an
> owner name in a certain name interval exist in a domain (or that any
> specific names in that interval are masked by a wildcard).
>
> The owner name of the NX RR is an existing name in the zone.  It's 
> RDATA
> is another existing name in the zone.  The presence of the NX RR means
> that no name between its owner name and the name in its RDATA area
> exists.  This implies a canonical ordering of all domain names in a
> zone.
>
> The ordering is to sort labels as unsigned left justified octet strings
> where the absence of a byte sorts before a zero byte.  Names are then
> sorted by sorting on the highest level label and then, within those
> names with the same highest level label by the next lower label, etc.
> Since we are talking about a zone, the zone name itself always exists
> and all other names are the zone name with some prefix of lower level
> labels.  Thus the zone name itself always sorts first.
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 3]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> There is a slight problem with the last NX in a zone as it wants to 
> have
> an owner name which is the last existing name is sort order, which is
> easy, but it is not obvious what name to put in its RDATA to indicate
> the entire remainder of the name space.  This is handled by treating 
> the
> name space as circular and putting the zone name in the RDATA of the
> last NX.
>
> There are additional complexities due to interaction with wildcards as
> explained below.
>
> The NX RRs for a zone can be automatically calculated and added to the
> zone by the same recommended off-line process that signs the zone.  The
> NX RRs TTL should not exceed the zone minimum TTL.
>
> The type number for the NX RR is xxx.
>
>
>
> W.3.2 NX RDATA format
>
> The RDATA for an NX RR consists simply of a domain name.
>
>
>                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     next domain name                                          /
> /                                                               /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> W.3.3 Interaction of NX RRs and Wildcard RRs
>
> As a wildcard RR causes all possible names in an interval to exist,
> there should not be an NX record that would cover any part of this
> interval.  Thus if *.X.ZONE exists you would expect an NX RR that ends
> at X.ZONE and one that starts with the last name covered by *.X.ZONE.
> However, this "last name covered" is something very ugly and long like
> \255\255\255....X.zone.  So the NX for the interval following is simply
> given the owner name *.X.zone.  This "*" type name is not expanded when
> the NX is returned as additional information in connection with a query
> for a non-existent name.
>
> If there could be any wildcard RRs in a zone and thus wildcard NXs, 
> care
> must be taken in interpreting the results of explicit NX retrievals as
> the owner name may be a wildcard expansion.
>
> The existence of one or more wildcard RRs covering a name interval 
> makes
> it possible for a malicious server to hide any more specificly named 
> RRs
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 4]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> in the internal.  The server can just falsely return the wildcard match
> instead of the more specificly named RRs.  If there is a zone wide
> wildcard, there will be only one NX RR whose owner name and RDATA are
> both the zone name.  In this case a server could conceal the existence
> of any more specific RRs in the zone.  It would be possible to make a
> more complex NX feature, taking into account the types of RRs that did
> not exist in a name interval, and the like, which would eliminate this
> possibility.  But it would be more complex and would be so constraining
> as to make any future dynamic update feature very difficult.  See
> Section xxx.
>
> Below is the sample zone given above with NX RRs added.
>
>      FOO. IN     SOA  QQ.FOO.  admin.QQ.FOO.
>                       (   60   ; serial
>                           7200  ; refresh
>                           600  ; retry
>                           1000000  ; expire
>                           60  ; minimum
>                       )
>                  NS      QQ
>                  NS      X.BAR
>                  MX  10  A1
>                  MX  99  QQ
>                  NX      A1
>
>      A1          A       192.0.2.252
>                  A       192.245.52.250
>                  MX  10  A1
>                  MX  99  QQ
>                  NX      BAR
>
>      X.BAR       A       192.0.2.253
>                  A       192.245.52.249
>                  MX  10  X.BAR
>                  MX  80  Y.Z.BAR
>                          ; no NX, covered by *.BAR
>
>      Y.Z.BAR     A       192.245.52.248
>                  MX  10  Y.Z.BAR
>                  MX  80  Z.BAR
>                          ; no NX, covered by *.BAR
>
>      *.BAR       MX  10  Y.Z.BAR
>                  MX  80  X.BAR
>                  NX      QQ
>
>      QQ          A       192.0.2.254
>                  MX  10  QQ
>                  MX  50  A1
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 5]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>                  NX      FOO.
>
>
>
> W.3.4 Blocking NX Pseudo-Zone Transfers
>
> In a secure zone, a resolver can query for the initial NX associated
> with the zone name.  Using the RDATA field from that RR, it can query
> for the next NX RR.  By repeating this, it can walk through all the NXs
> in the zone.  If there are no wildcards, it can use this technique to
> find all names in a zone. If it does type ANY queries, it can
> incrementally get all information in the zone and perhaps defeat
> attempts to administratively block zone transfers.
>
> If there are any wildcards, this NX walking technique will not find any
> more specific RR names in the part of the name space the wildcard
> covers.  By doing explicit retrievals for wildcard names, a resolver
> could determine what intervals are covered by wildcards but still could
> not, with these techniques, find any names inside such intervals.
>
> If it is desired to block NX walking, the recommended method is to add 
> a
> zone wide wildcard of the KEY type which asserts the nonexistence of 
> any
> keys.  This will cause there to be only one NX RR in the zone for the
> zone name and leak no information about what real names exist in the
> zone.  This protection from pseudo-zone transfers is bought at the
> expense of eliminating the data origin authentication of the non-
> existence of names that NX RRs can provide.  If an entire zone is
> covered by a wildcard, a malicious server can return an RR produced by
> matching that wildcard and can thus hide all the real data and
> delegations with more specific names in the zone.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 6]
> 
>
> --------
>
>

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 23:59:25 +0200

Surely someone would have come up with the following "solution" sooner or
later, I just didn't know it was as soon as 10 years back :-)

> > If it is desired to block NX walking, the recommended method is to add a

Obviously a wildcard in the "registry zone" eliminates the need for any
NXDOMAIN response and thus any "link" information coming from NSEC RRs, so
that the "pointer" part may carry bogus information. Now, that's replacing the
devil with ... and I can't believe me writing this.

-Peter

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