Re: Some notes on DNSCurve
Stephane Bortzmeyer
Jon A. Solworth <solw...@rites.uic.edu> wrote
a message of 63 lines which said:
> 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.
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
> does 1024-bit RSA.
As mentioned here, DNSSEC could use elliptic curves:
<http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key>
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Florian Weimer
> 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.
> 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.
DNSSEC requires support for intermediate resolvers, too, otherwise you
won't see the DS and RRSIG RRs on the stub.
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Ted Lemon
> 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.
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.
Paul Hoffman
>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
> 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.
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
Ted Lemon
> 2. The cache has to get the data from a reliable (i.e.
> authenticated) source.
So it has to use DNSSEC.
Mark Andrews
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: Mark_A...@isc.org
Paul Hoffman
>>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?
>its an IP which
>has been seen before and if so lookup its key.
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
--
Mark Andrews
> Ted Lemon wrote:
> > On Sep 4, 2008, at 2:18 PM, Jon A. Solworth wrote:
> >> 2. The cache has to get the data from a reliable (i.e.
> >> authenticated) source.
> >
> > So it has to use DNSSEC.
> >
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Ted Lemon
> No. It doesn't use signatures, but uses authenticated
> 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?
Stephane Bortzmeyer
> 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"?
Stephane Bortzmeyer
Ond??ej Surı <ondre...@nic.cz> wrote
a message of 7 lines which said:
> 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
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.
Paul Hoffman
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
--
Stephane Bortzmeyer
Paul Hoffman <paul.h...@vpnc.org> wrote
> 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.
bman...@vacation.karoshi.com
> Ben Laurie wrote:
> >Jon A. Solworth wrote:
> >
> >>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?
> >
> 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
bman...@vacation.karoshi.com
> bman...@vacation.karoshi.com wrote:
> >
> > 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
> >
> >
> 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
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.
Alex Bligh
--On 7 September 2008 21:54:48 -0700 Eric Rescorla
<e...@networkresonance.com> wrote:
> think there's a missing word here, namely: non-blind.
>
> Preventing blind attacks is a simple matter of adding more entropy to
> the queries.
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
Stephane Bortzmeyer
Alex Bligh <al...@alex.org.uk> wrote
> 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.
Alex Bligh
--On 8 September 2008 09:40:26 +0200 Stephane Bortzmeyer
<bortz...@nic.fr> wrote:
>> 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.
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
Florian Weimer
> Some of the observed behavior is probably just a way of working around
> broken resolvers / client programs that do not properly select a
> random host when more than one is available.
RFC 3484 prescribes an algorithm which does not select hosts randomly.
> DNS is not a good vehicle for implementing large scale load balancing,
> as it imposes unreasonable loads on clients and caches. Instead
> routing techniques seem more appropriate to me, such as Anycast.
I disagree. Host load-balancing should not be implemented at the
routing layer. (Exceptions exist for infrastructure services.) The
reason is that a domain name is much cheaper than a global routing
table slot.
On the other hand, I don't think DNS needs to accommodate services
which require fast-changing DNS data at the cost of other design
goals.
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
--
Dean Anderson
On Tue, 14 Oct 2008, Florian Weimer wrote:
> > Some of the observed behavior is probably just a way of working around
> > broken resolvers / client programs that do not properly select a
> > random host when more than one is available.
>
> RFC 3484 prescribes an algorithm which does not select hosts randomly.
And there is no requirement in any draft that a resolver select a random
host when more than one is available.
> > DNS is not a good vehicle for implementing large scale load
> > balancing, as it imposes unreasonable loads on clients and caches.
> > Instead routing techniques seem more appropriate to me, such as
> > Anycast.
Anycast is not suitable for stateful services, such as those over TCP,
and some UDP services are also stateful. (RFC1546 states that
explicitly)
> I disagree. Host load-balancing should not be implemented at the
> routing layer. (Exceptions exist for infrastructure services.) The
> reason is that a domain name is much cheaper than a global routing
> table slot.
>
> On the other hand, I don't think DNS needs to accommodate services
> which require fast-changing DNS data at the cost of other design
> goals.
Exactly right. I would add that load balancing is an application layer
service. The load balancer generally has have enough application
specific information to be able to keep the application state correct
amount the balanced hosts.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000