NSEC+-epsilon (whitelies server) proof of concept.

["Olaf M. Kolkman" <[e-mail]>]

Dear Colleagues,

<hat chair=off geek=on>

I have implemented a "proof-of-concept" server for the "white lies" scheme. 

Although there are a number of optimizations one can do I have found
this server to interoperate with a bind verifying nameserver.

Rough outline.

The sever itself is a proxy implemented in perl. After applying some
local policy it will forward all its queries to a BIND nameserver that
serves a specially prepared zone. Based on the answer being a wildcard
match, a NOERROR/empty answer match or an NXDOMAIN match the proxy
will cook up the appropriate NSEC white lies that "surround" the query.

The nearest successor and predecessor are determined as in
draft-sisson-dnsext-dns-name-p-s (with specification bugs corrected
and reported to the author) without any possible optimizations.


In more detail.
 
The zone preparations is done as follows.

An input zone is stripped from all its security related RRs (RRSIG,
NSEC, and DNSKEY). For each domain name "dname" in the zone that is
not a delegation a "dname+epsilon TXT " RR is created.

To this zone the keyset needs to be appended an then the zone is
signed through the regular BIND dnssec-signzone signer.

After the signing process all RRs with owner name "dname+epsilon" are
stripped. The result is a signed zone with NSEC RRs pointing to
"dname+epsilon" instead of the next dname.

This zone is loaded on a BIND nameserver running on a private address.

When the proxy receives a query it will return a "REFUSE" if the query
name contains "\000" or "\255" in one of its labels. This policy is
not strictly needed but it is to address the issue that the the NSEC
next name should be part of the zone.  By refusing queries for the
names that contain the "maximum and minimum sort values" that have
been inserted in the +-epsilon process, we "weasel" our way out of the
question if these names are or are not in the zone, the client will
just never be able to know because of our policy.

The proxy will forward its question to the BIND nameserver.

If the answer returned from the authoritative BIND server is a "No
Data" error:

  - the server take the packet coming from the BIND backend server
    and strip all NSECs and their RRs if the owner name is not the
    same as the qname and which are not owned by wildcard names (this
    preservers the NSEC RRs generated in the preprocessing phase and
    that are relevant for the proof).

  - It will then assess if the query was terminated in a wildcard
    match and add proof for non-existence of the direct match against
    the qname (it generates a name error) and return the answer to the
    client.

  - If the no data error was due because of a match against an empty
    non-terminal then a qname-epsilon NSEC qname+epsilon RR will be
    added to the proof to the client.

If the answer returned from the authoritative BIND server is a "name
error" (NXDOMAIN). 

  - A proof qname+epsilon NSEC qname+delta NULL proof will be supplied.
    the delta is somewhat bigger than the epsilon, that is qname+delta
    is the first successor of qname that does not prepend a label.

More detail you can find in the source which is available at
http://www.kolkman.org/NSECepsilon/


The proxy runs at 193.0.3.29. It is authoritative for eg.secret-wg.org. There
exists a secure delegation from secret-wg.org. 

Some of the zone content (not all, the challenge is to enumerate it and
provide me with the zone content :-) )



 *.foo                   10      TXT     "Wildcard match *.foo"

 bla.foo                 10      TXT     "direct match bla.foo"

 *.bla.foo               10      TXT     "direct match *.bla.foo"

 hidden.foo              10      TXT     "direct match hidden.foo"

 foo                     10      TXT     "direct match foo"

 ifeelso.empty   10      A       10.0.0.1




 
Please let me know if you think I overlooked an important protocol
feature or you find incorrect proofs. The whole point of this
exercise is to proof this can be done.

TODO:

There are a number of optimizations one can do based on the zone content
and structure. This has not been done yet.



</hat>

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC


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