Subject: George Barwood's Birthday Observation...

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Sep 2008 07:34:48 -0700

I think lost in George Barwood's discussion on convergence was this  
cool little observation of his when using duplication to increase  
entropy on resolvers which return different results:

If a nameserver returns K out of N randomly, the number of queries to  
get a single consistent mapping is actually very low:  The birthday  
paradox sees to that.

Even if K=1, this means a reasonable convergence rate will be achieved.

If a nameserver returns K out of N deterministically (eg, round- 
robin), it will take up to N/K queries however.

I still favor treating transaction and cache separately for purposes  
of protection under duplication, however.

--
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: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 03 Sep 2008 17:10:14 +0200

Nicholas Weaver wrote:
> I think lost in George Barwood's discussion on convergence was this cool
> little observation of his when using duplication to increase entropy on
> resolvers which return different results:
> 
> If a nameserver returns K out of N deterministically (eg, round-robin),
> it will take up to N/K queries however.

Smart use of the math in a positive manner.

> I still favor treating transaction and cache separately for purposes of
> protection under duplication, however.

What I think is more reprehensible in Barwood's convergence algorithm is
that it does not treat RRsets as the base unit of information. RRsets
should not be picked apart or assembled by the resolver.

Best regards,
   Wouter

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Sep 2008 08:45:10 -0700

> should not be picked apart or assembled by the resolver.

If the model for convergence is RRset, however, then the convergence  
problem gets VERY bad, as rather than 1 matching when you get K out of  
N each try, its all K have to match and you will NEVER converge in  
practice if K > 1.

One other thought on blind transaction attacks:  Can anyone come up  
with a case beyond cookie-stealing where you can do "race until win",  
that is, you need to trick the victim into fetching an ARBITRARY  
subname in a domain AND acting on that particular subname in a  
dangerous manner.

Because a blind transaction attack on a single name is "race every  
TTL" unless you have that "fetch arbitrary subname and act on it"  
property.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Sep 2008 10:00:34 -0700

On Sep 3, 2008, at 9:57 AM, Paul Vixie wrote:

> there's no reason to suppose that variance will be of round robin or
> any other K of N form.  load balancers could have undefined N.

N is at most the # of routed addresses on the Internet.  So there is a  
bound on N, even in the case of a funky P2P load-balancer where every  
host on the net may be a potential client.

However, that is large ENOUGH that you can call it unbounded.

Has anyone done a survey of such volatile authorities?  In many ways,  
we are speculating here.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Sep 2008 16:57:01 +0000

---

From: Brian Dickson <[email-masked]>
Date: Wed, 03 Sep 2008 13:35:04 -0400

> host on the net may be a potential client.

K of N is only true if previous connection state in some ways depends on 
the previous connection state.
Round robin, hash function, whatever.

If no connection state is kept (or not kept for a more than a trivial 
duration), any new connection is likely to be given a "random" load 
balancing target.

This is some kind of probability curve, with a tail that goes to 
infinity, although with correspondingly small probability values.

It is not bounded on any finite value, however, up to the limits of the 
PRNG cycle period (e.g. 2^64). We may as well consider it unbounded.

> Has anyone done a survey of such volatile authorities?  In many ways, 

There are folks on here who operate such authorities, e.g. TLDs.

Not keeping state is an important scaling characteristic, so it would be 
best to presume that (K of N) will be the exception rather than the rule...

Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Wed, 03 Sep 2008 18:51:22 -0400

Brian Dickson wrote:
>> N is at most the # of routed addresses on the Internet.  So there is 
>> a bound on N, even in the case of a funky P2P load-balancer where 
>> every host on the net may be a potential client.
>>
>
> K of N is only true if previous connection state in some ways depends 
> on the previous connection state.
> It is not bounded on any finite value, however, up to the limits of 
> the PRNG cycle period (e.g. 2^64). We may as well consider it unbounded.

My bad - I mis-read the context of the question below...

> Not keeping state is an important scaling characteristic, so it would 
> be best to presume that (K of N) will be the exception rather than the 
> rule...

My answer was answering another question - what about authorities that 
send queries to different servers via load-balancers?

However, the load-balancer question is pretty much orthogonal to the K 
of N thing.
For a given query, IMHO, the answer should be a complete RRset, or 
suitable response if it won't fit. All or nothing, not some subset that 
fits.

And the answer shouldn't change based on which server the load-balancer 
goes to.

BTW - in this context, "load balancer" means a thing acting as a proxy 
to a bunch of DNS authority servers.
It has nothing to do with *using* DNS to achieve load balancing at a 
higher level, e.g. via indirection (a la akamai).

Brian

---

From: "Jon A. Solworth" <[email-masked]>
Date: Wed, 03 Sep 2008 20:58:38 -0500

I went to DJB's talk at UIC on DNSCurve, and think its a very 
interesting proposal---and
was a bit disappointed that it wasn't explored more on namedroppers.  I 
just recently
subscribed, so please forgive me for not replying to the earlier 
thread.  I'll comment
on a few issues:

1. Authentication and trust anchor: DNSCurve is just like an RSA scheme 
in this
    regard.  The installed software must contained a trust anchor (the 
public key)
    and then that is used, in the normal way, to find other keys by 
reachability through
    chaining.  This problem is no different than its occurrence in DNSSEC.

2. Cryptographic scheme: DNSCurve protects the communication links from 
attackers rather
    than the DNS records from modification.  The advantage is that the 
relatively expensive operations
    involving the public/private key occur only once between each pair 
of hosts.  These operation
    produce a secret key which is then used to encrypt future requests 
using symmetric encryption,
    which on the order of a handful of cycles per byte.

3. Security: DNSCurve achieves much stronger cryptographic security then 
does 1024-bit RSA.
    In addition, since it reduces per query computational requests, it 
is harder to do a denial
    of service by flooding a cache with bogus responses.  It also 
provides much stronger protections'  
    against forgery then does DNSSEC because it uses a higher grade 
security.

4. DNSCurve does require the private key to be kept on line.  It is 
necessary to protect this
     private key against being stolen.  Its a good idea to have the 
cache the only software which
     runs on the host, or at least to run it in a separate virtual 
machine.  The advantage, though, is that
     signature verification is not needed on every request, that network 
bandwidth is saved,
     and packet pressure for UDP not unduly increased.

Jon

-- 
______________________________________________________________________________
Jon A. Solworth       		
Associate Professor and		home: http://www.rites.uic.edu/~solworth
  Director, Center for RITES	center: http://www.rites.uic.edu
Computer Science Dept.		kernelSec: http://www.kernelSec.org
  (m/c 152)	 		
Univ. of Illinois at Chicago   	telephone: (312) 996-0955
851 S. Morgan Rm 1120 SEO    	FAX:       (312) 413-0024  	
Chicago, IL 60607-7053

---

From: Duane at e164 dot org <[email-masked]>
Date: Thu, 04 Sep 2008 12:56:17 +1000

> 1. Authentication and trust anchor: DNSCurve is just like an RSA scheme

I've slowly been going through a similar process to come up with a
similar solution to the same problem, so far everything is still a work
in progress although I have no problem with combining resources/efforts
so as long as we get a suitable solution to this problem.

http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft
http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes
http://open-pgp.info/wiki/index.php?title=Why_X.509_is_Bad

> 3. Security: DNSCurve achieves much stronger cryptographic security then

There is a lot of question marks over EC, especially the NSA's actions
surrounding it.

> necessary to protect this

How's this different than webservers running https?

-- 

Best regards,
 Duane

---

From: "George Barwood" <[email-masked]>
Date: Thu, 4 Sep 2008 06:57:01 +0100

> suitable response if it won't fit. All or nothing, not some subset that 

Should the question of RRset integrity ( which was only introduced in RFC 
2181 "Clarifications to the DNS Specification" in 1997 ), be  dependent on 
which types are present in a response.

For example if there are only A, MX, NS and PTR records, I cannot see how 
RRset integrity is important, at least where non-deterministic responses are 
observed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 4 Sep 2008 09:43:22 +0200

On Wed, Sep 03, 2008 at 08:58:38PM -0500,
 Jon A. Solworth <[email-masked]> wrote 
 a message of 63 lines which said:

> interesting proposal---and was a bit disappointed that it wasn't
> explored more on namedroppers.

There are several reasons:

1) djb did not take the trouble to publish anything looking like a
specification (even with a very broad definition of "specification").

2) djb is well known for some good ideas and a complete lack of human
interface. He gets the attention he deserves.

> I just recently subscribed, so please forgive me for not replying to
> the earlier thread.

I forgive but stealing a thread is unforgivable: 
<http://wiki.exim.org/MailingListEtiquette#head-3eecd2d24196805f2f08fedc828108dd89aa37cb>

> 2. Cryptographic scheme: DNSCurve protects the communication links
> from attackers rather than the DNS records from modification.  The
> advantage is that the relatively expensive operations involving the
> public/private key occur only once between each pair of hosts.

And the disadvantage is that a non-DNScurve cache in the middle
completely stops DNScurve (while DNSSEC still works).

> 3. Security: DNSCurve achieves much stronger cryptographic security then  

As mentioned here, DNSSEC could use elliptic curves: 
<http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key>

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 4 Sep 2008 07:53:07 -0700

I think the most effective way is to start with a matrix:

Authenticates communication channel: DNSCurve
Authenticates the data:              DNSSEC

as a consequence:
Confidentiality on the wire:         DNSCurve only
Confidentiality from the resolver:   None
Recursive Resolver untrusted:        DNSSEC only
Trust Anchor Issues:                 Both (so same deployment  
headaches really)
Load on authority:                   Much higher for DNSCurve
Load on resolver:                    ?Slightly lower? for DNSCurve

Here are some observations on DNSSEC:

It doesn't have to trust the recursive resolver.  IF you are going to  
go through the effort of a cryptographic solution, I believe its key  
to minimize the trust.

As such, the recursive resolver can be lazy on signature verification  
if it knows the clients support DNSSEC. Thus in that case, the load  
from DNSSEC is actually lower even to the recursive resolver, and the  
load on the client resolvers is trivial.

This also separates out transport.  Anyone can tell you a record in  
DNSSEC.  I don't see a huge benefit to that, but its better than  
DNSCurve which requires online communication.

And on DNSCurve:

The confidentiality on the wire is ALMOST an illusion for most sites.   
Given traffic analysis and other issues, just traffic analysis (even  
on the basic graph of "who talks to who") is sufficient to eliminates  
MOST of the confidentiality present in DNSCurve.

DNSCurve increases the authority load by a massive amount.

I also wonder about the belief that it significantly reduces the load  
on the resolving cache compared to DNSSEC, even when the resolver does  
verify signatures.  Here's why:  It ONLY reduces the load when the  
resolver continues to communicate with that authority.  Are there some  
traces/analysis justifying this assumption?

DNSCurve has a worse partial deployment problem than DNSSEC.  DNSSEC  
requires the final stub resolver and the authority to support DNSSEC  
to gain a benefit.  DNSCurve requires the entire 3-party path of stub  
resolver, recursive resolver, and authority to support it.

I'm NOT a fan of DNSSEC.  I think DNSSEC is an utter and complete  
waste of time, and should only ever be deployed if some "compliance"  
requirement forces you to.

Its generally tackling the wrong problem:  If you have a Man-in-the- 
Middle, all the protocols using DNS are either sunk as well or never  
trusted the DNS name, so DNS actually needs to be the last thing  
secured against a MitM, not the first.

But by such notion, I'm LESS a fan of DNSCurve!  DNSCurve doesn't  
actually protect the real resources in DNS, the Name->value mappings,  
from being tampered with!

I believe that cryptographic security for DNS is not the solution to  
systemic problems with a man in the middle.  But, in my opinion,  
authenticating the communication rather than the data is not even the  
solution for cryptographically securing DNS!

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 11:26:43 -0500

> specification (even with a very broad definition of "specification").
    I think this could best be called at the proposal stage.  I don't
think DJB would consider writing a specification before he has an
implementation.
> interface. 
    What does human interface have to do with network protocol?
(OT: IMHO, the most important part of the human interface is the clarity
of ideas that underly it.)
> He gets the attention he deserves.
>   
    Would that it was true.  If he got the attention he deserved, everyone
would have implemented port randomization years ago.  
> <http://wiki.exim.org/MailingListEtiquette#head-3eecd2d24196805f2f08fedc828108dd89aa37cb>
    Unintentional, I assure you.  I claim mitigating circumstances but 
please no contest.
> completely stops DNScurve (while DNSSEC still works).
    On the contrary, DNSCurve is the same as DNSSEC in this regard.
You need a complete chain of DNSCurve (respectively DNSSEC) from
trust anchor to final name resolution for the translation to be secure.
Without this complete chain, you are subject to cache poisoning attacks
starting at that level.  DNSCurve simply looks at the nameserver's name
to see whether it has a key embedded in it to determine which one of
these cases exist.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 04 Sep 2008 19:01:24 +0200

> Load on resolver:                    ?Slightly lower? for DNSCurve

DNSCurve's alleged security level is beyond 2048 bit RSA keys, and the
speed comparison is based on that.  Public key operations for smaller
RSA keys are actually faster than their DNSCurve equivalent.

> resolver, recursive resolver, and authority to support it.

DNSSEC requires support for intermediate resolvers, too, otherwise you
won't see the DS and RRSIG RRs on the stub.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 4 Sep 2008 19:05:01 +0200

MjAwOC85LzQgSm9uIEEuIFNvbHdvcnRoIDxzb2x3b3J0aEByaXRlcy51aWMuZWR1PjoKPj4gMikgZGpiIGlzIHdlbGwga25vd24gZm9yIHNvbWUgZ29vZCBpZGVhcyBhbmQgYSBjb21wbGV0ZSBsYWNrIG9mIGh1bWFuCj4+IGludGVyZmFjZS4KPgo+ICAgV2hhdCBkb2VzIGh1bWFuIGludGVyZmFjZSBoYXZlIHRvIGRvIHdpdGggbmV0d29yayBwcm90b2NvbD8KPiAoT1Q6IElNSE8sIHRoZSBtb3N0IGltcG9ydGFudCBwYXJ0IG9mIHRoZSBodW1hbiBpbnRlcmZhY2UgaXMgdGhlIGNsYXJpdHkKPiBvZiBpZGVhcyB0aGF0IHVuZGVybHkgaXQuKQoKV2VsbCwgaW4gdGhlIHdvcmxkIG9mIGh1bWFucyB0aGlzIGlzIG5vdCB0cnVlLiAgQnV0IHdlIHNob3VsZCBub3Qgc3RyYXkKZnJvbSBkbnNleHQgdG8gcHN5Y2hvbG9neS4KCj4+PiAyLiBDcnlwdG9ncmFwaGljIHNjaGVtZTogRE5TQ3VydmUgcHJvdGVjdHMgdGhlIGNvbW11bmljYXRpb24gbGlua3MKPj4+IGZyb20gYXR0YWNrZXJzIHJhdGhlciB0aGFuIHRoZSBETlMgcmVjb3JkcyBmcm9tIG1vZGlmaWNhdGlvbi4gIFRoZQo+Pj4gYWR2YW50YWdlIGlzIHRoYXQgdGhlIHJlbGF0aXZlbHkgZXhwZW5zaXZlIG9wZXJhdGlvbnMgaW52b2x2aW5nIHRoZQo+Pj4gcHVibGljL3ByaXZhdGUga2V5IG9jY3VyIG9ubHkgb25jZSBiZXR3ZWVuIGVhY2ggcGFpciBvZiBob3N0cy4KPj4+Cj4+Cj4+IEFuZCB0aGUgZGlzYWR2YW50YWdlIGlzIHRoYXQgYSBub24tRE5TY3VydmUgY2FjaGUgaW4gdGhlIG1pZGRsZQo+PiBjb21wbGV0ZWx5IHN0b3BzIEROU2N1cnZlICh3aGlsZSBETlNTRUMgc3RpbGwgd29ya3MpLgo+Pgo+Pgo+Cj4gICBPbiB0aGUgY29udHJhcnksIEROU0N1cnZlIGlzIHRoZSBzYW1lIGFzIEROU1NFQyBpbiB0aGlzIHJlZ2FyZC4KPiBZb3UgbmVlZCBhIGNvbXBsZXRlIGNoYWluIG9mIEROU0N1cnZlIChyZXNwZWN0aXZlbHkgRE5TU0VDKSBmcm9tCj4gdHJ1c3QgYW5jaG9yIHRvIGZpbmFsIG5hbWUgcmVzb2x1dGlvbiBmb3IgdGhlIHRyYW5zbGF0aW9uIHRvIGJlIHNlY3VyZS4KPiBXaXRob3V0IHRoaXMgY29tcGxldGUgY2hhaW4sIHlvdSBhcmUgc3ViamVjdCB0byBjYWNoZSBwb2lzb25pbmcgYXR0YWNrcwo+IHN0YXJ0aW5nIGF0IHRoYXQgbGV2ZWwuICBETlNDdXJ2ZSBzaW1wbHkgbG9va3MgYXQgdGhlIG5hbWVzZXJ2ZXIncyBuYW1lCj4gdG8gc2VlIHdoZXRoZXIgaXQgaGFzIGEga2V5IGVtYmVkZGVkIGluIGl0IHRvIGRldGVybWluZSB3aGljaCBvbmUgb2YKPiB0aGVzZSBjYXNlcyBleGlzdC4KCkkgdGhpbmsgd2hhdCBTdGVwaGFuZSBzYWlkIHdhcyB0aGF0IGlmIHlvdSBoYXZlIHRoaXMgc2NlbmFyaW86CgpjbGllbnQgLS0gZm9yd2FyZGVyMiAtLSBmb3J3YXJkZXIxIC0tIGF1dGhvcml0eQoKdGhlbiBETlNTRUMgc3RpbGwgd29ya3MgZXZlbiBpZiBmb3J3YXJkZXIxIG9yIGZvcndhcmRlcjIgZG9lc24ndCB2YWxpZGF0ZSBETlNTRUMKCk9uZHJlagotLSAKIE9uZMWZZWogU3Vyw70KIHRlY2huaWNrw70gxZllZGl0ZWwvQ2hpZWYgVGVjaG5pY2FsIE9mZmljZXIKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBDWi5OSUMsIHoucy5wLm8uICAtLSAgLmN6IGRvbWFpbiByZWdpc3RyeQogQW1lcmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6ICBodHRwOi8vbmljLmN6Lwogc2lwOm9uZHJlai5zdXJ5QG5pYy5jeiB0ZWw6KzQyMC4yMjI3NDUxMTAKIG1vYjorNDIwLjczOTAxMzY5OSAgICAgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 12:07:34 -0500

> Load on resolver:                    ?Slightly lower? for DNSCurve
Some comments on the details above.
    Load on authority:  When comparing the load on the authority one 
must compare the increased network
                                     load of DNSSEC vs. the increase 
crypto load of DNSCurve (DNSCurve also increases
                                     network load but far less than does 
DNSSEC).  Because of the caching of public key
                                     computations, the crypto cost is 
very low.  Note that the caching is possible because
                                     the session is essentially 
arbitrarily long.
    Load on resolver:    Resolver needs to do public key operations only 
when connecting to a name server
                                     which it has not previously connected.

> go through the effort of a cryptographic solution, I believe its key 
        Granted, you need to have a trusted cache.  Don't trust the 
cache someone else's cache,
set up your own.  Also trust is important, but also need to pay careful 
attention to availability.
 
> load on the client resolvers is trivial.
    But then the cache can be poisoned.  It doesn't cause integrity 
problems since the client covers
but if the resolver gets behind it definitely leads to availability issues.
> DNSCurve which requires online communication.
    The Internet is designed to support on-line operation :-).
> MOST of the confidentiality present in DNSCurve.
    DNScurve confidentiality prevents network reconnaissance.
> DNSCurve increases the authority load by a massive amount.
    I don't think this is true.  For each authority, the first time a 
cache tries to contact
it the public key operation must be performed.  After that the result 
can be saved
by the authority and only symmetric cryptography operations are needed.  The
symmetric cryptography can be quite inexpensive.
> traces/analysis justifying this assumption?
    Well, certainly there is significant reuse as timeouts for DNS 
information range from a minute or so
to days.   So assuming the names are still in use, they will need to be 
re-fetched.  On the other hand,
if you don't have significant reuse on that scale, then you can argue 
that the total amount of public
key operations are not a problem because of the limit on the number of 
hosts.
> resolver, recursive resolver, and authority to support it.
    This is no different than with DNSSEC.  The authority must support 
DNSSEC, otherwise you get no DNSSEC protections.
An authority implemented DNSSEC must implement software changes to 
support it in many more places than DNSCurve,
which requires some name changes and some communications changes.
> Its generally tackling the wrong problem:  If you have a 
> Man-in-the-Middle, all the protocols using DNS are either sunk as well 
> or never trusted the DNS name, so DNS actually needs to be the last 
> thing secured against a MitM, not the first.
>
    DNSCurve trusts certain entitles to provide the mapping.   That is 
inherent.
    DNSCurve (like DNSSEC) prevents integrity problems, but not 
availability problems, from a MitM attack.  This is important.
    DNSCurve (like DNSSEC) do not fix the IP problem

> solution for cryptographically securing DNS!
    Different tradeoffs.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Sep 2008 17:13:12 +0000

> ...

if we're doing a matrix, then other columns are "masataka ohta's proposal"
and "doing nothing", and other rows are "cost of starting over" and "length
of time remaining before the proposal is a multi-vendor specification ready
for global deployment".

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 4 Sep 2008 19:05:01 +0200

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 12:43:11 -0500

> of time remaining before the proposal is a multi-vendor specification ready
    I think Paul is addressing the right issues.   Here is my framing of
the relevant questions

    1. What does it cost going forward?  (Past expenditures, i.e. sunken 
costs
        are irrelevant).
    2. What does it take to provide a solution for *all* DNS servers/caches?
    3. How difficult is it to move to producers/consumers of DNS info to 
this solution?
    4. When can we expect complete specifications?
    5. What are the security implications?

Jon

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Sep 2008 18:06:17 +0000

>    I think Paul is addressing the right issues.  Here is my framing of

i think you're disagreeing with me far more than you're agreeing.

> costs are irrelevant).

if it's going to take N years for specification, interoperability testing,
vendor adoption, operational testing, operator adoption, industry adoption,
and N is set by the size and complexity of the dns market not by the size
or complexity of the security standard, then past expenditures CAN be
relevant.

>    2. What does it take to provide a solution for *all* DNS servers/caches?

what it takes is acceptance, motivation, inertia, and drive.  code is small
by comparison, even all the code in all the servers, all added together.

>    3. How difficult is it to move to producers/consumers of DNS info to

this isn't important at all.  normal capitalistic effects will produce tools
people can use.  apple and microsoft have made no commitment to dnssec tools
but if either one does, then other will, and then it's all just drop down
menus and fanciness, and the underlying technology will be hidden from most
of the people who have to use it.

>    4. When can we expect complete specifications?

never?  all internet specifications are subject to revision.  the better
question is "what's the projected calendar date of the final flag day upon
which all prior implementations will become invalid, like NCP/IP once was."

>    5. What are the security implications?

including downgrade attack vulnerabilities when a responder doesn't implement
what an initiator is hoping for, and/or when the data you'd like to validate
has no signatures yet.

the purpose of the matrix should be to determine whether to tear back open
this can of worms and say that 13 years just isn't long enough for Secure DNS,
let's start over.

i say this as a man who has quashed four of my own proposals which i knew were
better than dnssec but which i did not think i could bring to market faster.
conservation of momentum is a valid principal of engineering economics, more
so than the number of bits or CPU cycles shown on a whiteboard or in an
academic paper or a demo codebase.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Sep 2008 13:57:55 -0700

> attention to availability.

Where does the cache get its trustworthy data?   Isn't this question  
the basis for the whole discussion we've been having the past couple  
of weeks?   It doesn't matter how much trust you personally feel for  
the person who is running your cache.   What matters is whether or not  
the data in the cache is in fact trustworthy.

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 16:13:30 -0500

Ondřej Surý wrote:
> 2008/9/4 Jon A. Solworth <[email-masked]>:
>   
> Well, in the world of humans this is not true.  But we should not stray
> from dnsext to psychology.
>
>   
> I think what Stephane said was that if you have this scenario:
>
> client -- forwarder2 -- forwarder1 -- authority
>
> then DNSSEC still works even if forwarder1 or forwarder2 doesn't validate DNSSEC
>   
    Thanks for the clarification.  Yes, it requires your caches 
(forwarders) to
speak DNSSEC (or lose the protections).  Of course, DNSSEC requires your
client to check the software or lose protections.  I don't see much of a 
difference here.

Jon
> Ondrej

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 16:18:16 -0500

> the data in the cache is in fact trustworthy.
Two issues here:
    1. With DNSCurve, your cache has to be trustworthy, since if it changed
        the data, you would never know.  DNSSEC cache changes are 
detectable,
        which is good, but there are both security and usability issues 
associated
        with that.
    2. The cache has to get the data from a reliable (i.e. 
authenticated) source.

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 17:00:54 -0500

> i think you're disagreeing with me far more than you're agreeing.
    I didn't intend to be.  But I think some discussion might help bring
us closer together, and if not at least help understand the differences.
> or complexity of the security standard, then past expenditures CAN be
    Actually, it doesn't matter at all (well OK, there may be some minor 
accounting
issues associated with it but from an economic viewpoint its irrelevant).
Suppose I invested a million dollars in X.  Then I decide that Y is 
equivalent
to X.  Now to complete X it takes $100,000 and to do Y from scratch it 
takes $1,000.  Are
you really suggesting that it makes sense to spend $100,000 more when
you can get the same benefit for $1,000?

    Here is another analogy.  I bought a computer last year for $5,000.  
I can get the
same computer now for $500.  How much is the computer I bought for 
$5,000 worth?
Certainly less than $500 because its not new.  (If the new computer 
costs $1, then
the original computer is worth no more than $1).

> by comparison, even all the code in all the servers, all added together.
    This may indeed be a minor issue.  But its still necessary to 
determine that.
My understanding is that there is an issue which extends beyond DNS software
into backends which are effectively not standardized.
> of the people who have to use it.
    A solution needs to get people to adopt the new technology and my 
understanding
is that there is a problem with that.   I see your Apple and Microsoft 
statements as---
at best--beside the point.  Why would either of them make a commitment 
to DNS tools?
Your assuming that (1) good tools can be built and (2) people will want 
to buy them or
that someone will pay for them so that they can provided for "free".

> which all prior implementations will become invalid, like NCP/IP once was."
    Complete is not the same as final.

    Paul, perhaps this is a political issue, but I really feel 
uncomfortable with
relying on coercion to get a solution adopted.  As a technologist, I 
think that
such a methodology always leads to poor solutions.  Many times, the solution
fails (or is delayed time and time again) because the cure is so 
unpalatable.

    By the way NCP/IP was 25 years (I had to look it up, I originally 
thought you were
refering van Jacobson flag day).

> academic paper or a demo codebase.
    I know that this process is frustrating.  And 13 years is a long time.
DJB's proposal is much more modest then DNSSEC, and maybe that's a good
thing.  I think a technical evaluation of a way forward, and an openness to
ideas--including Ohta's--would be a good thing.

Jon

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Sep 2008 15:24:40 -0700

At 8:58 PM -0500 9/3/08, Jon A. Solworth wrote:
>from attackers rather
>    than the DNS records from modification.  The advantage is that 
>the relatively expensive operations
>    involving the public/private key occur only once between each 
>pair of hosts.  These operation
>    produce a secret key which is then used to encrypt future 
>requests using symmetric encryption,

I have looked at Dan's slides and his web site (dnscurve.org), and I 
don't see this. In fac, the opposite seems to be true. It looks like 
the requester and the responder do an ECDH with every request.

If you are correct and there is a long-lived secret key produced, how 
is that key kept? In specific, how does the responder know to use the 
key with the next request?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Ondřej Surý" <[email-masked]>
Date: Fri, 5 Sep 2008 01:00:44 +0200

MjAwOC85LzUgSm9uIEEuIFNvbHdvcnRoIDxzb2x3b3J0aEByaXRlcy51aWMuZWR1PjoKPj4+ICAgMS4gV2hhdCBkb2VzIGl0IGNvc3QgZ29pbmcgZm9yd2FyZD8gIChQYXN0IGV4cGVuZGl0dXJlcywgaS5lLiBzdW5rZW4KPj4+IGNvc3RzIGFyZSBpcnJlbGV2YW50KS4KPj4+Cj4+Cj4+IGlmIGl0J3MgZ29pbmcgdG8gdGFrZSBOIHllYXJzIGZvciBzcGVjaWZpY2F0aW9uLCBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcsCj4+IHZlbmRvciBhZG9wdGlvbiwgb3BlcmF0aW9uYWwgdGVzdGluZywgb3BlcmF0b3IgYWRvcHRpb24sIGluZHVzdHJ5Cj4+IGFkb3B0aW9uLAo+PiBhbmQgTiBpcyBzZXQgYnkgdGhlIHNpemUgYW5kIGNvbXBsZXhpdHkgb2YgdGhlIGRucyBtYXJrZXQgbm90IGJ5IHRoZSBzaXplCj4+IG9yIGNvbXBsZXhpdHkgb2YgdGhlIHNlY3VyaXR5IHN0YW5kYXJkLCB0aGVuIHBhc3QgZXhwZW5kaXR1cmVzIENBTiBiZQo+PiByZWxldmFudC4KPj4KPj4KPgo+ICAgQWN0dWFsbHksIGl0IGRvZXNuJ3QgbWF0dGVyIGF0IGFsbCAod2VsbCBPSywgdGhlcmUgbWF5IGJlIHNvbWUgbWlub3IKPiBhY2NvdW50aW5nCj4gaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBpdCBidXQgZnJvbSBhbiBlY29ub21pYyB2aWV3cG9pbnQgaXRzIGlycmVsZXZhbnQpLgo+IFN1cHBvc2UgSSBpbnZlc3RlZCBhIG1pbGxpb24gZG9sbGFycyBpbiBYLiAgVGhlbiBJIGRlY2lkZSB0aGF0IFkgaXMKPiBlcXVpdmFsZW50Cj4gdG8gWC4gIE5vdyB0byBjb21wbGV0ZSBYIGl0IHRha2VzICQxMDAsMDAwIGFuZCB0byBkbyBZIGZyb20gc2NyYXRjaCBpdCB0YWtlcwo+ICQxLDAwMC4gIEFyZQo+IHlvdSByZWFsbHkgc3VnZ2VzdGluZyB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHNwZW5kICQxMDAsMDAwIG1vcmUgd2hlbgo+IHlvdSBjYW4gZ2V0IHRoZSBzYW1lIGJlbmVmaXQgZm9yICQxLDAwMD8KPgo+ICAgSGVyZSBpcyBhbm90aGVyIGFuYWxvZ3kuICBJIGJvdWdodCBhIGNvbXB1dGVyIGxhc3QgeWVhciBmb3IgJDUsMDAwLiAgSSBjYW4KPiBnZXQgdGhlCj4gc2FtZSBjb21wdXRlciBub3cgZm9yICQ1MDAuICBIb3cgbXVjaCBpcyB0aGUgY29tcHV0ZXIgSSBib3VnaHQgZm9yICQ1LDAwMAo+IHdvcnRoPwo+IENlcnRhaW5seSBsZXNzIHRoYW4gJDUwMCBiZWNhdXNlIGl0cyBub3QgbmV3LiAgKElmIHRoZSBuZXcgY29tcHV0ZXIgY29zdHMKPiAkMSwgdGhlbgo+IHRoZSBvcmlnaW5hbCBjb21wdXRlciBpcyB3b3J0aCBubyBtb3JlIHRoYW4gJDEpLgoKV2lzaCBpdCB3ZXJlIHNvIHNpbXBsZS4gIChOb3cgSSBzcGVhayBhcyByZWdpc3RyeSB3aGljaCBpcyBnb2luZyB0bwpkZXBsb3kgRE5TU0VDCnRoaXMgbW9udGguKSAgSXQncyBub3QgYWxsIGFib3V0IHRoZSBtb25leS4gIEl0J3MgdGhlIHRydXN0IG9mIHRoZSB1c2Vycwp3ZSBhcmUganVnZ2xpbmcgaGVyZS4gIEkgaGF2ZSBub3QgcHJvYmxlbSBkcm9wcGluZyBETlNTRUMgb24gdGhlIGZsb29yIGJlY2F1c2UKb2Ygc29tZSBmYXRhbCBmbGF3IGZvdW5kIGluIGl0LiAgQnV0IGNhbiB3ZSAoYW5kIGl0IGFwcGxpZXMgdG8gLnNlLAouYmcsIC5wciwgLmJyCmFuZCBJQU5BKSBqdXN0IGNvbWUgYW5kIHNheTogT29vcHMsIGFsbCB3cm9uZywgbGV0J3MgdHJ5ICc8cmVwbGFjZQp3aXRoIHJhbmRvbSB3b3JkPicKbm93LCB0aGlzIHRpbWUgd2UgZ290IGl0IGZvciByZWFsLgoKSWYgdGhlcmUgaXMgdGVjaG5vbG9neSB3aGljaCBpcyBnb2luZyB0byByZXBsYWNlIEROU1NFQyB0aGVuIGl0IG11c3QKcGxheSB3ZWxsIHdpdGgKRE5TU0VDLCBzbyB3ZSBjYW4gZGVwbG95IGl0IHRvZ2V0aGVyIHdpdGggZXhpc3RpbmcgRE5TU0VDIGluc3RhbGF0aW9ucwphbmQgd2UgY2FuCmRlY2lkZSB3aGVuIChhbmQgaWYpIHdlIGRyb3AgRE5TU0VDIGFzIG9ic29sZXRlLgoKT25kcmVqLgotLSAKIE9uZMWZZWogU3Vyw70KIHRlY2huaWNrw70gxZllZGl0ZWwvQ2hpZWYgVGVjaG5pY2FsIE9mZmljZXIKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBDWi5OSUMsIHoucy5wLm8uICAtLSAgLmN6IGRvbWFpbiByZWdpc3RyeQogQW1lcmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6ICBodHRwOi8vbmljLmN6Lwogc2lwOm9uZHJlai5zdXJ5QG5pYy5jeiB0ZWw6KzQyMC4yMjI3NDUxMTAKIG1vYjorNDIwLjczOTAxMzY5OSAgICAgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Sep 2008 16:06:30 -0700

>    2. The cache has to get the data from a reliable (i.e.

So it has to use DNSSEC.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Sep 2008 10:04:17 +1000

DNSCurve and TKEY don't work well with anycast (local or
	global) as they require multiple UDP round trips with
	anything to identify a "session".  Both will require a inter
	server protocol to disperse negotiated keys.

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

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 19:03:36 -0500

> the requester and the responder do an ECDH with every request.
    The slides are a bit dense (It helps to attend the talk :-)  We 
tried to record it but had technical difficulties.
Here is the relevant slide, I've added editorial content as lines 
beginning with "++" .  DJB's slide start with ==

== Whenever cache sees a
== new public key Curve25519(s)
== it computes Curve25519(sc).

++ public keys are connected to nameservers.  This says the
++ function Curve25519(sc) is computed once per public key.
++ note that s and c are private keys of the server respectively.
++ the crypto function is based on Diffie-Hellman without either
++ server (respectively client) disclosing s (resp. c).

== Core 2 Quad Q6600 can do this
== 25000 times per second
== using latest Curve25519 software.

++ 25000 previously unseen caches can be computed per second
++ by each server.

== Per-packet costs: much smaller;
== pure secret-key cryptography.
== Similar speed for server.

++ pure secret-key = symmetric cryptograph

== Many new clients per second;

++ fast public key cryptography

== many more packets per second.

++ fast symmetric cryptography

> key with the next request?
    Hmm.   I guess using the source IP on the request.  Find out if its 
an IP which
has been seen before and if so lookup its key.

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 19:11:32 -0500

>>    2. The cache has to get the data from a reliable (i.e.
No.  It doesn't use signatures, but uses authenticated
and encrypted links instead.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Sep 2008 17:29:30 -0700

At 7:03 PM -0500 9/4/08, Jon A. Solworth wrote:
>>If you are correct and there is a long-lived secret key produced, 
>>how is that key kept? In specific, how does the responder know to 
>>use the key with the next request?
>    Hmm.   I guess using the source IP on the request.  Find out if 
>its an IP which

This may be an example of why others on this thread indicated that 
seeing the actual proposal would be helpful when deciding whether or 
not this is a good idea. Protocol design choices like this can show 
whether or not the proposal might subject the authoritative servers 
to trivial CPU-exhaustion attacks.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 20:31:33 -0500

Paul Hoffman wrote:
> whether or not the proposal might subject the authoritative servers to 
> trivial CPU-exhaustion attacks.
    Certainly its good to be skeptical.  On the other hand, DJB pays 
very careful attention to denial
of service attacks and anti-clogging attacks meant to prevent CPU 
exhaustion.  Note that his pages
make specific claims on DoS advantages.

    And it would be good if there was more info to better understand 
DNSCurve and to compare it with alternatives.

Jon

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Sep 2008 11:40:50 +1000

> and encrypted links instead.

	And we all *know* that *no* ISP will replace a response
	with another one.

	This is not to say that hop-by-hop security may not be
	useful.

	There are other mechanisms which can be used to protect a
	referral.  Signing the delegating NS RRset and signing the
	glue willl be just as effective.  The later would require
	a new type to hold the signature.

	Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Sep 2008 19:11:42 -0700

> and encrypted links instead.

This seems like a rather large key distribution problem.   Are you  
sure that when all is said and done you won't wind up right back at  
DNSSEC?

---

From: "Jon A. Solworth" <[email-masked]>
Date: Thu, 04 Sep 2008 21:21:03 -0500

> sure that when all is said and done you won't wind up right back at 
Same key distribution problem.  That's inherent in a distributed 
authentication
problem.  But DNSCurve has different security properties, usability issues,
and performance issues.

Jon

---

From: Paul Vixie <[email-masked]>
Date: Fri, 05 Sep 2008 02:43:20 +0000

> 	server protocol to disperse negotiated keys.

i've always expected that servers in an anycast cluster will flood tkey
state to each other privately, to maintain the illusion of a single server.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 5 Sep 2008 10:13:58 +0200

On Thu, Sep 04, 2008 at 04:13:30PM -0500,
 Jon A. Solworth <[email-masked]> wrote 
 a message of 62 lines which said:

> Yes, it requires your caches (forwarders) to speak DNSSEC (or lose
> the protections).  Of course, DNSSEC requires your client to check
> the software or lose protections.  I don't see much of a difference
> here.

I cannot parse here. Is the first word "DNSSEC" actually "DNScurve"?

And what does it mean for the client to "check software"?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 5 Sep 2008 10:12:25 +0200

On Thu, Sep 04, 2008 at 07:05:01PM +0200,
 Ond??ej Surý <[email-masked]> wrote 

> then DNSSEC still works even if forwarder1 or forwarder2 doesn't validate DNSSEC

Yes. And, even better, DNSSEC works even if a secondary name server is
compromised (something that DNScurve does not do). DNSSEC protects the
whole chain from the (possibly stealth) primary name server to the
validating resolver.

---

From: "Ondřej Surý" <[email-masked]>
Date: Fri, 5 Sep 2008 10:46:38 +0200

MjAwOC85LzUgU3RlcGhhbmUgQm9ydHptZXllciA8Ym9ydHptZXllckBuaWMuZnI+Ogo+IE9uIFRodSwgU2VwIDA0LCAyMDA4IGF0IDA0OjEzOjMwUE0gLTA1MDAsCj4gIEpvbiBBLiBTb2x3b3J0aCA8c29sd29ydGhAcml0ZXMudWljLmVkdT4gd3JvdGUKPiAgYSBtZXNzYWdlIG9mIDYyIGxpbmVzIHdoaWNoIHNhaWQ6Cj4KPj4gWWVzLCBpdCByZXF1aXJlcyB5b3VyIGNhY2hlcyAoZm9yd2FyZGVycykgdG8gc3BlYWsgRE5TU0VDIChvciBsb3NlCj4+IHRoZSBwcm90ZWN0aW9ucykuICBPZiBjb3Vyc2UsIEROU1NFQyByZXF1aXJlcyB5b3VyIGNsaWVudCB0byBjaGVjawo+PiB0aGUgc29mdHdhcmUgb3IgbG9zZSBwcm90ZWN0aW9ucy4gIEkgZG9uJ3Qgc2VlIG11Y2ggb2YgYSBkaWZmZXJlbmNlCj4+IGhlcmUuCj4KPiBJIGNhbm5vdCBwYXJzZSBoZXJlLiBJcyB0aGUgZmlyc3Qgd29yZCAiRE5TU0VDIiBhY3R1YWxseSAiRE5TY3VydmUiPwoKSSB0aGluayAidG8gc3BlYWsgRE5TU0VDIiBtZWFucyAidG8gaG9ub3IgRE8gYml0IiBpbiB0aGlzIGNvbnRleHQuCgpPbmRyZWoKLS0gCiBPbmTFmWVqIFN1csO9CiB0ZWNobmlja8O9IMWZZWRpdGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAtLSAuY3ogZG9tYWluIHJlZ2lzdHJ5CiBBbWVyaWNrw6EgMjMsMTIwIDAwIFByYWhhIDIsQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogaHR0cDovL25pYy5jei8KIHNpcDpvbmRyZWouc3VyeUBuaWMuY3ogdGVsOis0MjAuMjIyNzQ1MTEwCiBtb2I6KzQyMC43MzkwMTM2OTkgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Jon A. Solworth" <[email-masked]>
Date: Fri, 05 Sep 2008 08:13:25 -0500

Ondřej Surý wrote:
> 2008/9/5 Stephane Bortzmeyer <[email-masked]>:
>   
    Yes your read is correct, sorry for the confusion
>
> I think "to speak DNSSEC" means "to honor DO bit" in this context.
>
> Ondrej
>

---

From: "Jon A. Solworth" <[email-masked]>
Date: Fri, 05 Sep 2008 08:35:16 -0500

Ondřej Surý wrote:
> 2008/9/5 Jon A. Solworth <[email-masked]>:
>   
>> to X.  Now to complete X it takes $100,000 and to do Y from scratch it takes
>> $1,000.  Are
>>   Here is another analogy.  I bought a computer last year for $5,000.  I can
>> get the
>> same computer now for $500.  How much is the computer I bought for $5,000
>> worth?
>> Certainly less than $500 because its not new.  (If the new computer costs
>> $1, then
> Wish it were so simple.  (Now I speak as registry which is going to
> deploy DNSSEC
> this month.)  It's not all about the money.  It's the trust of the users
> we are juggling here.  I have not problem dropping DNSSEC on the floor because
> of some fatal flaw found in it.  But can we (and it applies to .se,
> .bg, .pr, .br
> and IANA) just come and say: Ooops, all wrong, let's try '<replace
> with random word>'
> now, this time we got it for real.
>
> If there is technology which is going to replace DNSSEC then it must
> play well with
> DNSSEC, so we can deploy it together with existing DNSSEC instalations
> and we can
> decide when (and if) we drop DNSSEC as obsolete.
>
> Ondrej.
>   
    Interesting point.

    I think it would not be very difficult to build a gateway so that
you point to one place if you run DNSSEC and another if you
run DNSCURVE.  Note that DNS software installations need to
specify their roots, so different services could be pointed to different
servers.  The DNSCurve gateway, for example, could dynamically
translate DNSSEC signed records to DNSCurve (and vice versa).

Jon

---

From: Jefferson Ogata <[email-masked]>
Date: Fri, 05 Sep 2008 13:58:06 +0000

> whole chain from the (possibly stealth) primary name server to the

One thing unclear to me: if a validating end resolver is using a 
non-validating, intermediate cache, and a DNSSEC answer fails to 
resolve, how does the end resolver convince the cache to look up the 
broken record again?

Seems to me that caches need at least to respect flags requesting 
validation in order to prevent bogus records from getting stuck in the 
cache for the entire TTL. Or else, end resolvers need to fall back to 
full resolution mode if the cache returns bogus data.

-- 
Jefferson Ogata : Internetworker, Antibozo

---

From: Ben Laurie <[email-masked]>
Date: Sun, 07 Sep 2008 14:01:55 +0100

Jon A. Solworth wrote:
>>> $5,000

Not vice versa. This is the whole point of DNSSEC.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: "Jon A. Solworth" <[email-masked]>
Date: Sun, 07 Sep 2008 09:19:17 -0500

> Not vice versa. This is the whole point of DNSSEC.
    Nope.  They completely interoperate.

    Its not too difficult to make a DNSCurve to DNSSEC gateway.
The DNSSEC gateway has to fetch the DNSCurve information,
and then create (and sign) the DNSSEC records.  Note that the
signatures for DNSCURVDE are all coming from the DNSSEC gateway, and that
the DNSSEC gateway has its own root of trust.

Jon

---

From: Ben Laurie <[email-masked]>
Date: Sun, 07 Sep 2008 15:31:17 +0100

Jon A. Solworth wrote:
> and then create (and sign) the DNSSEC records.

How can the gateway sign the DNSSEC records? It can only do that if it
is authoritative for the zone.

> Note that the
> signatures for DNSCURVDE are all coming from the DNSSEC gateway,

Eh? DNSCurve is an input to the gateway.

> and that the DNSSEC gateway has its own root of trust.

Who cares? Its the resolver's root of trust that matters. Or are you
saying that all resolvers behind the gateway use a root key belonging to
the gateway?

Cheers,

Ben.

---

From: "Jon A. Solworth" <[email-masked]>
Date: Sun, 07 Sep 2008 10:04:07 -0500

> Eh? DNSCurve is an input to the gateway.
   Yes, reads better when its written "signature for DNSCurve supplied 
information..."

> saying that all resolvers behind the gateway use a root key belonging to
    Yes, that's what I'm saying.  Of course, the two base schemes
(before considering the gateway) have different security properties
so we're going to need in the gateway to create signatures on-line,
or something close to it.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 07 Sep 2008 16:42:04 +0100

> the DNSSEC gateway has its own root of trust.

OK, so this isn't really a DNSCurve to DNSSEC gateway, just something
that talks the protocol without following the rules.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Sep 2008 09:23:14 -0700

Proposal: we stop talking about DNSCurve until we know what it is.

Many of us, including Jon Solworth, are making assertions about what 
DNSCurve is that cannot be verified because there is no protocol 
description. I suspect that when Dan Bernstein writes up the first 
Internet Draft (if he does so), the protocol will look quite 
different than what we are guessing at.

What we can reliably take away from the discussion so far is that 
DNSCurve uses elliptic curve crypto using a curve that Dan 
co-authored to establish a shared private encryption key between a 
DNS cache and an authoritative resolver. Beyond that, it's all 
guesses.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jon A. Solworth" <[email-masked]>
Date: Sun, 07 Sep 2008 12:38:29 -0500

> that talks the protocol without following the rules.
    Yes.   Note, however, that for either scheme the correctness of
every authentication depends on the root of trust.  (Abuse of
protocol is a long standing Internet tradition.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 7 Sep 2008 22:19:10 +0200

On Sun, Sep 07, 2008 at 09:23:14AM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 21 lines which said:

> assertions about what DNSCurve is that cannot be verified because
> there is no protocol description.

Correct.

> I suspect that when Dan Bernstein writes up the first Internet Draft
> (if he does so), 

IMHO, it is not necessary to produce an "Internet-Draft" (a thing
published at the IETF and following the rules of RFC 2026, 2223, etc).

*Any* published specification would work for me. Today, we just have
handwaving.

---

From: [email-masked]
Date: Mon, 8 Sep 2008 00:56:07 +0000

On Sun, Sep 07, 2008 at 10:04:07AM -0500, Jon A. Solworth wrote:
>    Yes, that's what I'm saying. 

	so, this works best when there is no mobility of the end resolver and
limited description of conflict resolution when there are multiple gateways.
How does one manage an emergency/unscheduled requirement to "rollover" the "root of trust"?

--bill

---

From: "Jon A. Solworth" <[email-masked]>
Date: Sun, 07 Sep 2008 20:51:09 -0500

> How does one manage an emergency/unscheduled requirement to "rollover" the "root of trust"?
    Let me make clear that the gateway discussion was just a thought of how
DNSSEC and DNSCurve might co-exist.  Its not part of the DNSCurve proposal,
and indeed there might be better ways to inter-operate.   Its premature to
flesh out these issues.

    The next step is an implementation of DNSCurve.  Among other things, it
will be possible to measure the performance overheads of DNSCurve.

Jon

---

From: [email-masked]
Date: Mon, 8 Sep 2008 02:15:01 +0000

> will be possible to measure the performance overheads of DNSCurve.

	ok.  if those issues are not to be addressed, i'd appreciate a clear
problem statement for which an DNSCurve is the solution. Just writing code to 
write code is fine, but most folks have a particular problem in mind before they
start crafting a solution.  

--bill

---

From: "Jon A. Solworth" <[email-masked]>
Date: Sun, 07 Sep 2008 21:52:26 -0500

> start crafting a solution.  
    DNSCurve purpose is to provide a light-weight scheme for protecting
DNS caches from protcol-based cache poisoning attacks.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 07 Sep 2008 21:54:48 -0700

At Sun, 07 Sep 2008 21:52:26 -0500,
> DNS caches from protcol-based cache poisoning attacks.

I think there's a missing word here, namely: non-blind.

Preventing blind attacks is a simple matter of adding more entropy to
the queries.

-Ekr

---

From: Alex Bligh <[email-masked]>
Date: Mon, 08 Sep 2008 08:20:05 +0100

--On 7 September 2008 21:54:48 -0700 Eric Rescorla 
<[email-masked]> wrote:

>  think there's a missing word here, namely: non-blind.
>

Also (and it's a little bizarre to be guessing the problem specification
based on a largely undocumented solution), it would seem only to address
cache poisoning by insertion of an answer by a party other than that
queried. Unless I'm missing something (other than a full spec!) it doesn't
itself address cache poisoning where a DNS server which has received a
query (either legitimately, or due to some insertion attack on NS
records) sends deliberately bogus responses.

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Sep 2008 09:40:26 +0200

On Mon, Sep 08, 2008 at 08:20:05AM +0100,
 Alex Bligh <[email-masked]> wrote 
 a message of 24 lines which said:

> it doesn't itself address cache poisoning where a DNS server which
> has received a query (either legitimately, or due to some insertion
> attack on NS records) sends deliberately bogus responses.

Yes, but this is probably what Jon A. Solworth meant by restricting to
"protocol-based" attacks.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 08 Sep 2008 09:28:02 +0100

> "protocol-based" attacks.

These could still be protocol based. I am speculating (as I haven't
seen the spec), but assume recursive server R uses DNScurve to communicate
with authoritative server A1. An attack is still possible if A1 itself
is bogus as R got the address for A1 from an attack on a non-DNScurve
lookup at A2 by M (i.e. unless there was DNScurve from root down, there
is no true security, the very same criticism often leveled at DNSSEC).
Equally, if R uses DNSCurve to communicate (correctly) with an
authoritative server A3 controlled by M, M can could cause records to
be introduced into A3's reply which have an effect on domains for which
M / A3 isn't meant to be able to affect (e.g. returning false glue);
of course other protocols suffer from the same weakness and there are
bailliwick checks designed to get around these, but my point is they
are not a problem DNScurve seeks to address (as I understand it).

Alex

---

From: David Ulevitch <[email-masked]>
Date: Wed, 10 Sep 2008 22:24:59 -0700

> 	server protocol to disperse negotiated keys.

This is not true.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Sep 2008 07:03:23 +0000

> This is not true.

indeed, i had it explained to me yesterday that dnscurve places the key
that allows a nameserver to speak for a zone into each NS RR for that
zone.  so while there's some state, it's no worse than having to keep
every bailiwick's NS RRset in memory (which we do anyway) and there are
no new round trips.

note that the property of dnscurve which makes this design possible is
the small size of the keys and signatures.  hiding a 1024 bit RSA or DSA
key in a 63-character DNS label with only six meaningful bits per cell
is impossible.  dnscurve, because of the size of its outputs, fits.  i
also heard from a crypto person (of which i am not one) that new curves
take as long as five years to gain credibility in the crypto community.
i do not know if any sufficiently-old-enough curve has outputs that will
fit in a DNS label, or if djb's current innovation is absolutely required.

however, this is all selling past the close.  if someone writes an I-D
then this group should look at it.  if it looks good then this group 
should try to decide whether to torch dnssec and start over with this.
but until then we're wasting time and bits discussing these details.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Sep 2008 11:54:13 -0400

Dear colleagues,

> Proposal: we stop talking about DNSCurve until we know what it is.

I think this is an excellent idea.  Note that it is entirely in
keeping with a previous note Olafur sent here, on behalf of both of
us:

http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01713.html

So, folks, _please_ can we focus our attention on the work the WG
needs to do?  We still have some WGLCs open, and it'd be nice to get
them sewn up.  I know that DNSCurve looks promising, but in the
absence of a complete description, our continued speculation is not
advancing in any way the specification of the DNS protocols. 

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/