Subject: dnscurve -- new or did I just miss this?

From: David Ulevitch <[email-masked]>
Date: Sat, 30 Aug 2008 13:33:00 -0700

http://dnscurve.org/

DNSCurve uses high-speed high-security elliptic-curve cryptography to 
drastically improve every dimension of DNS security:

     * Confidentiality: DNS requests and responses today are completely 
unencrypted and are broadcast to any attacker who cares to look. 
DNSCurve encrypts all DNS packets.
     * Integrity: DNS today uses "UDP source-port randomization" and 
"TXID randomization" to create some speed bumps for blind attackers, but 
patient attackers and sniffing attackers can easily forge DNS records. 
DNSCurve cryptographically authenticates all DNS responses, eliminating 
forged DNS packets.
     * Availability: DNS today has no protection against denial of 
service. A sniffing attacker can disable all of your DNS lookups by 
sending just a few forged packets per second. DNSCurve very quickly 
recognizes and discards forged packets, so attackers have much more 
trouble preventing DNS data from getting through. Protection is also 
needed for SMTP, HTTP, HTTPS, etc., but protecting DNS is the first step.

Despite its extremely high level of security, DNSCurve is very easy for 
software authors to implement, and very easy for administrators to deploy.

--
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: "Ondřej Surý" <[email-masked]>
Date: Sat, 30 Aug 2008 23:52:19 +0200

> dnscurve -- new or did I just miss this?

Created On:10-Aug-2008 06:32:59 UTC
Last Updated On:27-Aug-2008 13:17:39 UTC
Registrant Name:Daniel J. Bernstein

> http://dnscurve.org/

I have read those pages and as I understand them djb proposes
encrypting DNS communication (encapsulating it into TXT query
and response) when it sees some special string in domain
name ('uz5').

But since DNSCurve doesn't have trust anchors it does not protect
you before you get this new special name (which is distributed
by PODS).  I can even spoof DNSCurve nameserver and my *evil*
DNS server can talk DNSCurve protocol.  Basicaly it's like
self-signed certificates.

Or am I missing something?

Ondrej.
-- 
 Ondřej Surý
 technický ředitel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o. -- .cz domain registry
 Americká 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked] http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699 fax:+420.222745112
 -----------------------------------------
������r��zǧu���Ơz�'jg���iz�+z����)�'�~���+a����n�˛���m�jȧ�W��w���^��,j�{[�ܚ��b��m�����"z����l�v�y�覗��

---

From: [email-masked]
Date: Sat, 30 Aug 2008 22:38:39 +0000

>From my reading of it, the key is distributed in the domain name; one would need some secure (OOB) method to authenticate the domain names. One could have a trust anchor equivelant by only using pre-configured nameservers for certain domains, perhaps allowing parent nameservers to override it if they were quried using DNSCurve. If this were enabled at the root (<sarcasm>I'm sure that would not cause any load issues</sarcasm>), then no trust anchor would be needed for verification -- the root server names themselves could be used.

---

From: "Ondřej Surý" <[email-masked]>
Date: Sun, 31 Aug 2008 01:28:05 +0200

Sure, there are ways how to solve it, but quoting the page:
> No extra cache configuration is required; the DNS cache will figure out for itself when a server supports DNSCurve. No extra firewall configuration is required (if you have your cache behind a firewall); DNSCurve requests and responses are, from a firewall's perspective, normal DNS packets. Network bandwidth remains essentially unchanged; DNSCurve puts some extra information into packets to DNSCurve servers but does not use extra packets.

Anyway - let's suppose this is enabled in root (and we seeded our rdns
with root's DNSCurve nameservers) - wow now we have encapsulated EVERY
DNS packet into encrypted TXT packets.  It reminds me IP over DNS
protocol.

But it has some interesting ideas.  I am not a crypto guy, so maybe I
am wrong, but could we use that elliptic curve cryptography in place
of RSA?

Ondrej.
-- 
 Ondřej Surý
 technický ředitel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o. -- .cz domain registry
 Americká 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked] http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699 fax:+420.222745112
 -----------------------------------------
h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

From: [email-masked]
Date: Sat, 30 Aug 2008 23:43:10 +0000

> am wrong, but could we use that elliptic curve cryptography in place

I think so. RFC4034 defines algorithim number 4 for elliptic curves, but I don't see any definition for it's usage.

Implementors and cryptographers tend to be unfamiliar with elliptic curves, which is mildly scary. Elliptic curves are well supported by common crypto libraries, but still much less so than RSA - I doubt this would be a problem, though. RSA works, so there is little motivation to moving to elliptic curves.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 31 Aug 2008 14:38:50 +0200

In your previous mail you wrote:

  so there is little motivation to moving to elliptic curves.
   
=> I disagree:
 - ECs are faster than RSA and give smaller keys and signatures
 - ECs are based on a different mechanism than RSA, it is important
  to provide a choice between two basic mechanisms in case one of
  them is discovered far too weak (note this applies too to a EC
  only solution :-)
So IMHO it should be good to investigate about an ECDSA DNSSEC option.

Regards

[email-masked]

PS: cryptographers I know promote the use of ECs...

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 31 Aug 2008 08:05:19 -0700

> - ECs are faster than RSA and give smaller keys and signatures

This is true.  Especially if you want to maintain for, as much as  
possible, the DNS maximum message size over UDP.

> them is discovered far too weak (note this applies too to a EC

This I disagree with.

Although the elliptic curve discrete log problem (and the discrete log  
problem in general) are separate from the factoring problem, every  
breakthrough in one almost invariably produces a breakthrough in the  
other.

Of special worry is quantum computing, which affects ECC just the same  
as RSA, and is actually a footnote in the original quantum computing  
beats factoring paper.

Additionaly, there was a big discussion of this very problem at the  
AES candidate meeting in the "choose 1 algorithm or 2" discussion. In  
general, the crptographer's consensus is that only a single algorithm  
should be chosen, as actually specifying two opens up more  
vulnerabilities than a fallback provision provides.

Frankly speaking, the markeplace reason for a competitor to DNSSEC has  
to arrise from ease-of-use concerns, not choice of crypto.

---

From: "Blacka, David" <[email-masked]>
Date: Sun, 31 Aug 2008 11:33:52 -0400

On Aug 30, 2008, at 7:43 PM, [email-masked] wrote:

> I think so. RFC4034 defines algorithim number 4 for elliptic curves,  
> but I don't see any definition for it's usage.

There isn't one that made it through last call, but there is a  
proposed definition.  See: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/

There was the thought that this proposal was too wide open and thus  
too complex.  However, no one has (yet) published a DNSKEY proposal  
for a simpler version, or pushed harder for the existing version to  
move forward.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 31 Aug 2008 22:44:29 +0200

On Sun, Aug 31, 2008 at 11:33:52AM -0400,
 Blacka, David <[email-masked]> wrote 
 a message of 27 lines which said:

> There isn't one that made it through last call, but there is a proposed 
> definition.  See: 
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/

Warning, we are deriving into a general discussion on EC cryptography
and this thread, IMHO, should stay focused on DNScurve.

---

From: bert hubert <[email-masked]>
Date: Sun, 31 Aug 2008 23:11:25 +0200

> and this thread, IMHO, should stay focused on DNScurve.

Ah yes, very good. Ok - about there being no trust anchors, I don't think
this is explicit in the design. They just haven't been mentioned yet, but
I'm pretty sure they could be added out of band - for people who want to be
really sure.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 Aug 2008 22:38:43 +0000

> to arrise from ease-of-use concerns, not choice of crypto.

ease of use being an engineering problem, it seems quite soluble to me.

however, if we're going to reconsider "how to secure dns" and are therefore
willing to throw away the last 13 or so years of work and ditch the products
and vendors in this nascent industry, then i'd like it if masataka ohta's
proposal was also considered.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 31 Aug 2008 16:57:15 -0700

At Sun, 31 Aug 2008 08:05:19 -0700,
> possible, the DNS maximum message size over UDP.

It's not clear to me that signing computational performance is a
particularly major factor here, since DNSSEC is designed to avoid the
need for the signature to be recomputed for each request served, so
the only per-transaction overhead is verification. RSA verification is
extremely fast. For instance, on my MacBook Air, a single 1024-bit RSA
verification takes about 500us. Note that EC verification is actually
quite a bit slower than RSA verification up to large key sizes, so
this isn't an advantage of EC, really.

ISTM that the primary advantage of EC in DNSSEC is compactness
of representation:

         Pubkey Size (bits)        Signature Size (bits)
RSA                   1024*                         1024
ECDSA                 160**                        320**

*  Assumes that e is fixed, e.g., to F4. Otherwise, you need
   1-3 bytes to represent e
** With point compression and a single fixed EC curve.

There are other tradeoffs you can make. For instance, if all you care
about is signature size, you can do quite a bit better here. BLS
[BLS04] is a pairing-based signature scheme that has a 160-bit
signature.  An additional BLS benefit is that you can aggregate the
signatures.  I.e., you can produce a single signature that is 160-bits
long that combines two signatures by different signers, which lets you
compress signature chains.

Unfortunately, BLS verification performance is quite a bit slower than
RSA verification, probably more like RSA signing (I'm guessing order
25 ms, but I don't have current data). This doesn't seem like a real
problem for endhosts, but could certainly be one for recursive
resolvers. Also, the public keys are fairly large so it's not
clear that the public key + signature size is better than ECDSA.

FWIW Looking at dnscurve, it doesn't look like a signature-based
syste at all. Rather, the client and server do a DH exchange and use the 
DH shared secret to authenticate the data. This has a number of
obvious drawbacks in the DNS setting, including inability to
cache and online vulnerability of the server to private key
theft.

-Ekr

[BLS04] Dan Boneh, Ben Lynn, and Hovav Shacham, "Short Signatures
from the Weil Pairing", J. Cryptology, 17(4):297?319, Sep. 2004.