Subject: [dnsext] DNSCurve Internet-Draft

From: Matthew Dempsky <[email-masked]>
Date: Mon, 1 Mar 2010 14:59:33 -0800

I posted a -01 update of draft-dempsky-dnscurve to the IETF I-D
tracker; it's available at

    http://tools.ietf.org/html/draft-dempsky-dnscurve-01

Following Andrew Sullivan's recommendations, I suggest the DNSEXT WG
adopt it as a WG item.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 2 Mar 2010 10:49:21 +0100

On Mon, Mar 01, 2010 at 02:59:33PM -0800,
 Matthew Dempsky <[email-masked]> wrote 

> tracker; it's available at

I suggest to add a Changes section next time, to see what's new
(<http://tools.ietf.org/rfcdiff> seems down).

---

From: Federico Lucifredi <[email-masked]>
Date: Tue, 02 Mar 2010 11:54:55 -0500

> Following Andrew Sullivan's recommendations, I suggest the DNSEXT WG

I second that.

 Best -F

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: Federico Lucifredi <[email-masked]>
Date: Tue, 02 Mar 2010 13:26:01 -0500

> Following Andrew Sullivan's recommendations, I suggest the DNSEXT WG

I have noted down a few editing changes in my first pass on the doc, but
that may be premature until the technical discussion is taken care of.

There is a bigger problem I have with the document, which is that it is
a standards track document by label, but does not define the standard
internally, it relies on DJB's paper to cover essential process steps.

Sourcing DJB is good (indeed you SHOULD credit as appropriate), but the
RFC needs be self-contained or make reference to other RFCs to fully
cover all details of the process needed to create a full implementation:
the boxing-unboxing specification is missing here altogether. You need a
section specifying each, and replace references to such process (as in
section 2) to refer to those sections.

This is applicable in other places. in general, you want to split your
[naclcrypto] referencies between the place where you credit (where your
approach is fine) and the place where you refer to implementation
detail, which you should replace with pointers to the appropriate
(missing) doc sections.

Until this is done I see little point in focusing other details, which
are mostly editing for clarity, so I am omitting those. An RFC,
especially a standards track one, needs to define the process it is
standardizing. The current draft is not sufficient for me to create a
full implementation w/o relying on DJB's paper (which is a fine one),
please compare with the MD5 RFC (1321 IIRC), it quotes appropriate
sources but defines the process within the document, fully.

 Best - Federico

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Mar 2010 10:57:05 -0800

> (<http://tools.ietf.org/rfcdiff> seems down).

Thanks, will do.

For what it's worth, the only changes between -00 and -01 are
typographical fixes and wording changes to hopefully improve the
clarity.  Additionally, the xml master of the draft is being stored in
github: http://github.com/mdempsky/dnscurve/tree/master/drafts/

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 14:15:04 -0500

>  An RFC,
>standardizing.

Would it make more sense to see this as an Individual RFC or a WG 
Experimental RFC?  Not all RFCs have to be standards track.  And not 
all RFCs have to WG docs.

To the chairs - could you lay out the criteria and implications of a 
draft being a WG item and being Standards Track?

My fear is that if this document is taken to be a standards track 
document in the working group, it could get stalled for a long time. 
It might RFC-publish faster as experimental or an individual 
submission.  (After all, there's no need for any IANA actions.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Mar 2010 11:44:52 -0800

At 2:15 PM -0500 3/2/10, Edward Lewis wrote:
>To the chairs - could you lay out the criteria and implications of a draft being a WG item and being Standards Track?

In specific, if it becomes a WG work item, can the WG change major parts of the specification based on WG consensus?

--Paul Hoffman, Director
--VPN Consortium

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Mar 2010 11:43:00 -0800

> internally, it relies on DJB's paper to cover essential process steps.

Yeah, Paul Hoffman also warned me about this.  However, there seems to
be prior art of Standards Track RFCs referencing non-RFC works for
cryptographic primitive definitions.  E.g., while MD5 and SHA1 have
their own RFCs describing them, RC4, DES, 3DES, IDEA, Blowfish, AES,
Serpent, Twofish, SHA256, SHA512, RSA, DSA, ECDSA, etc. do not, but
are still used by SSH, TLS, and other Standards Track IETF protocols.

I'll write additional drafts describing Curve25519 et al if necessary,
but they seem superfluous to me given the number of other crypto
primitives that lack RFC descriptions.

That said, I'm not strongly opposed to adding additional references to
the draft (e.g., to the papers that introduced Curve25519, etc.), but
they at least seem unnecessary to me as all of the crypto operations
and assumptions DNSCurve relies on are defined within [naclcrypto].

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Mar 2010 12:21:35 -0800

> In specific, if it becomes a WG work item, can the WG change major parts of the specification based on WG consensus?

As I told Andrew Sullivan off-list when he suggested submitting it as
a WG item, the two concerns I have are that a) users of the existing
DNSCurve protocol are not adversely affected (e.g., if the protocol
changes in a backwards incompatible way, it should use new magic
numbers to allow coexistence), and b) if the protocol changes
significantly, then it receives a new name so that there's no
ambiguity about what supporting "DNSCurve" means.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Mar 2010 15:42:09 -0500

> draft being a WG item and being Standards Track?

These are different questions.  The criteria for an item being a WG
item has historically been pretty low: we just ask for at least five
people to commit to work on it.  I always try to be clear to authors
who bring us work that more is better, because if we get to WGLC and
there were only five people reviewing in the first place, and one of
them objects, the document will die.

The implications for something being on the Standards Track is that it
modifies the DNS standards.

The WG does not have to adopt a document to the Standards Track
either, of course.  We could adopt a document with another target
status.

Finally, to answer Paul Hoffman's question down-thread: if this or any
other document becomes a WG item, then it's the product of the WG and
not the original author.  That means that the WG can change it however
the WG wants.  We are supposed to be about interoperability, of
course, and therefore interoperation with actually deployed systems is
one important consideration in deciding whether to make changes.  But
it's _one_ consideration, not the only one.

Best,

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Mar 2010 15:43:35 -0800

On Tue, Mar 2, 2010 at 3:19 PM, George Barwood
<[email-masked]> wrote:
> It does require IANA action, in contrast to DNSCurve, but I believe it to be technically superior
> and a cleaner solution, more suitable as the basis for an IETF standard. I had previously implemented
> DNSCurve, but have now upgraded to this. An implementation is more complex, with more code
> than DNSCurve, but my position is that it's not sensible to adopt a partial solution.

I think that if IP fragmentation and/or TCP RST attacks are an attack
vector that users are concerned about, a better alternative to adding
more complexity to the DNS protocol is to use a DNSCurve-like encoding
of IPsec/IKE public keys (or hashes thereof) in name server names.
Then the application layer can continue using plain DNS over UDP/TCP
after alerting the IPsec stack of the server's public key.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 2 Mar 2010 23:19:12 -0000

----- Original Message ----- 
From: "Matthew Dempsky" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; "IETF DNSEXT WG" <[email-masked]>
Sent: Tuesday, March 02, 2010 8:21 PM
Subject: Re: [dnsext] what track for Re: DNSCurve Internet-Draft

> ambiguity about what supporting "DNSCurve" means.

I would draw the attention of the workgroup to this draft

http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-15

which incorporates the same cryptography (and other ideas) as DNSCurve, but has significant
improvements, and solves a larger set of problems ( essentially all the spoofing and denial of
service attacks that DNS is currently subject to, but also optimal performance ).

George Barwood

---

From: "George Barwood" <[email-masked]>
Date: Wed, 3 Mar 2010 00:14:13 -0000

----- Original Message ----- 
From: "Matthew Dempsky" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>; "Edward Lewis" <[email-masked]>; "IETF DNSEXT WG" <[email-masked]>
Sent: Tuesday, March 02, 2010 11:43 PM
Subject: Re: [dnsext] what track for Re: DNSCurve Internet-Draft

> after alerting the IPsec stack of the server's public key.

While I don't fully understand the solution you are suggesting :

(1) Fragmentation is always a problem, because fragments have to be held until the complete
packet is received. This creates a resource problem, as well as problems with routers/NAT devices,
and even spoofing weakness. Hence in my draft packets are always self-contained, smaller than
~1500 bytes (or a client specified limit) and can be authenticated without waiting for any other packets.

(2) Reflection attacks are another concern. If you regard availability as more important that authenticity
( which is arguable for DNS ), DNSSEC in it's current form could be a step backwards. I think the potential
for reflection attacks using authoritative servers is a significant concern ( as noted by Dr Bernstein ).

(3) I regard using name server names to encode keys as a reasonable "dirty" solution ( that can
work with existing infrastructure ), but using resource records should be the recommended solution,
with the name server name encoding method used only as a temporary kludge, while systems
are upgraded. I have previously explained that a resource record allows possibly hundreds of thousands
of domains to be protected with a single administrative action.

I would like to see availability, denial of service attacks and performance, taken seriously.
DNSCurve makes some progress, but as your draft acknowledges, still has some shortcomings,
that I hope and believe I have addressed.

Regards,
George Barwood

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Mar 2010 17:19:07 -0800

> While I don't fully understand the solution you are suggesting :

The general idea is that a recursive resolver wants to lookup
www.example.com, and it receives from the com servers:

    example.com. NS foo[K].example.com.
    foo[K].example.com. A 1.2.3.4

where [K] is an encoding of a public key K (or in the interest of
space, a hash Hash(K) or partial hash Hash(K)[0:N] of a public key).

The recursive resolver would then notify the IPsec stack to setup an
IPsec flow for UDP and TCP traffic to 1.2.3.4 port 53, and that the
remote host's public key is K (or has a key whose hash is Hash(K) or
starts with Hash(K)[0:N], respectively).  The IPsec stack would then
use IKE to negotiate a shared secret key with the authoritative
server.

Other than communicating with the IPsec stack the remote host's public
key (or hash) and which packets it expects to be IPsec protected, the
recursive server is otherwise unaffected (i.e., it can use plain DNS
over TCP and/or fragmented UDP without any security risks).

> for reflection attacks using authoritative servers is a significant concern ( as noted by Dr Bernstein ).

So from what I can tell, both of these are solved by simply not
sending large responses.  DNSSEC is the only use of DNS I know of that
depends upon large responses, and many mailing list posts have
amounted to DNSSEC proponents saying they're not concerned about these
risks.  Are there other users who need to send >512B responses but are
concerned about availability?

> of domains to be protected with a single administrative action.

I'm not opposed to having additional means of publishing DNSCurve
public keys, but something like the current solution is needed.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 3 Mar 2010 07:21:52 -0000

----- Original Message ----- 
From: "Matthew Dempsky" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>; "Edward Lewis" <[email-masked]>; "IETF DNSEXT WG" <[email-masked]>
Sent: Wednesday, March 03, 2010 1:19 AM
Subject: Re: [dnsext] what track for Re: DNSCurve Internet-Draft

> use IKE to negotiate a shared secret key with the authoritative

It sounds extremely inefficient and complex.

> concerned about availability?

AXFR also has large responses. Yes, DNSSEC is the obvious application that generates
large responses, but other certificates published in the DNS are other candidates.
 
> public keys, but something like the current solution is needed.

Yes, we agree here, except that I regard name server name encoding as "additional" ( and temporary,
where temporary might be many years or even decades ), with the RR representation being fundamental.

If the parent server does not support the new protocol, the gain in security from using name server
name encoding of a public key is marginal ( clients learn the key slightly later ). If they do support
the protocol, but there is no channel to communicate the public key to the parent zone, there is
a significant gain in security, but you would expect the parent to implement the required channel
( which is similar to sending glue A / AAAA records to the parent - although the parent could
also pull the record from the child using DNSSEC, for example ).

-- George Barwood

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Mar 2010 15:13:26 +0000

On Tue, 2 Mar 2010, George Barwood wrote:
> which incorporates the same cryptography (and other ideas) as DNSCurve,
> but has significant improvements, and solves a larger set of problems

I think this is a good direction to work in since it has the potential to
remove DNScurve's limitations. For example, you should add algorithm
agility to the protocol. (Hmm, isn't this a requirement for
standards-track protocols?)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Mar 2010 08:53:06 -0800

>It sounds extremely inefficient and complex.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Mar 2010 09:15:28 -0800

Executive summary of the following:

a)  DNSCurve's design provides almost no practical enhancement to system security.

b)  DNSCurve's implementation guarantees substantial deployment problems due to transport issues, because it doesn't parse as DNS and never considered why 512B is a "magic number" for DNS on the network.

As a result, DNSCurve should be rejected with extreme prejudice!

a:

There is no threat ANALYSIS in the security considerations at all, rather just statements like:

>    DNSCurve only provides link-level security between a client-server
>    pair.  It does not attempt to ensure end-to-end security for queries
>    and responses relayed by untrusted DNS proxies and caches.

Lets start with integrity, which what really counts in DNS:  The problem, simply put, is that any conventional threat analysis shows that link level integrity is almost useless:

You have out of path attackers and in-path attackers, and attackers on the link between the client and the recursive resolver, and between the recursive resolver and the general Internet.

Against out of path attackers, we have robust defenses both universally implemented (port randomization), and proposed with some implementation (glue validation, 0x20, EDNS0-based).  Did we fail in this?  I'm actually pretty confident we haven't, because we've enumerated the space and properties.  An attacker has to SEE the traffic in order to attack a modern recursive resolver

Thus DNSCurve is only providing integrity against in-path adversaries, which exist between the resolver and authority.

The problem is, simply put, DNS doesn't exist in a vacuum, DNS integrity is part of the final protocol.  And the final protocol either also trivially vulnerable to an in-path adversary, so DNScurve only provides protection when the in-path adversary is NOT on the final path of the application.  Practically put, this is a rare case.

Worse, there is one in-path adversary that IS significant for DNS, because it is NOT on the final path for data: the recursive resolver!  We have witnessed resolvers delivering malicious results, both due to malcode and due to "legitimate" activity of the resolver operator (yes, we've seen ISPs MitM www.google.com in DNS!).  Yet DNSCurve, by design, provides no message integrity, which is what's needed to deal with bad recursive resolvers.

So DNSCurve's integrity benefits are almost trivially useless!

Worse, DNSCurve's CONFIDENTIALITY attempts are almost as useless:  Even assuming complete deployment, if you are monitoring either the final authority or the resolver's outgoing requests, because you know who is talking to whom, AND the structure of the DNS hierarchy, AND the size of the responses.  

Thus for DNS, traffic analysis will work wonders, ensuring that there is no real confidentiality except in rare cases.  And really, the confidentiality risk is from the recursive resolver itself, eg, with some recursive resolvers (eg, Google Public DNS) really existing for the purpose of datamining the query stream.  Thus the claims of confidentiality should be completely dropped: they don't actually exist worth squat.

Oh, and despite the obsession with reflector attacks, DNSCurve has no impact on this, because you can just do large response reflector attacks from open resolvers: DNSSEC's large replies actually provide very little benefit for someone intelligent conducting a DNS reflector attack.

It is this sort of security analysis which is missing from the DNSCurve draft and, if included, makes one realize just how useless DNSCurve is. 

B:

Additionally, the implementation is CATASTROPHICALLY bad.  And I do mean catastrophically, based on my experience in measuring the network with Netalyzr and (in progress) direct probing of recursive resolvers.

If the goal is to avoid malfunctioning middleboxes, making DNSCurve packets non-parseable is a disaster.  We can't tell between resolver and authority, but the path between client and the net is FULL FULL FULL of devices which will block DNS traffic that's not valid DNS.  

On port 53, you MUST parse as DNS if you want any hope of reliable delivery, PERIOD.

This is a far bigger problem than the 512B limit, which is very low (a couple percent) on the resolver->authority path and client->authority path, which DNSCurve has an unreasonable obsession with.  (A far bigger problem is fragmentation, which is more like 1400+ bytes in practice).  

Additionally, any path which has a 512B limit is due to a DNS-aware middlebox.  How do you think such middleboxes are going to react to a non-valid message on port 53?  

Thus DNSCurve's "small packet" obsession for reliability is defeated utterly by DNSCurve's message format, which does not parse as valid DNS, because the design never considered WHY 512B was a "magic limit" in the network for DNS!

Thus as an implementation, DNSCurve MUST NOT produce data that is not parseable as DNS, as that WILL be blocked with far greater probability than packets of over 512B in size.

Rather, the client key MUST be contained in an EDNS resource record (this is exactly what EDNS is for!), and the response from the server MUST be completely encapsulated into an EDNS resource record (so a response with 0 answer, 0 auth, 1 EDNS0 in the additional, with the additional being an encryption of the "real" DNS response), as this is far more likely to be passed by the net unhindered and actually can respect the EDNS MTU.

Of course, if you are going to do this, you might as well also define keys in a resource record type as well, and gee, what do you get?  Well, something either like DNSSEC (if you use signatures on data for end-to-end integrity) or Barwood's proposal (if you do on-the-wire integrity/confidentiality)

As a consequence, DNSCurve should be rejected with extreme prejudice, and I mean extreme prejudice:

The architecture provides almost a trivially small increase in aggregate security

The implementation is critically, and completely broken in its objective because it uses opaque MESSAGES rather than opaque resource records.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 3 Mar 2010 17:17:58 -0000

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Matthew Dempsky" <[email-masked]>; "Paul Hoffman" <[email-masked]>; "Edward Lewis" <[email-masked]>; "IETF DNSEXT WG" <[email-masked]>
Sent: Wednesday, March 03, 2010 3:13 PM
Subject: Re: [dnsext] what track for Re: DNSCurve Internet-Draft

> remove DNScurve's limitations. 

Thanks for the support.

> For example, you should add algorithm

Good point, I will incorporate this in the next version of the draft.

George

---

From: Brian Dickson <[email-masked]>
Date: Wed, 3 Mar 2010 15:05:22 -0400

> Executive summary of the following:

[snip]

> b)  DNSCurve's implementation guarantees substantial deployment problems due to transport issues, because it doesn't parse as DNS and never considered why 512B is a "magic number" for DNS on the ne…

[snip]

> On port 53, you MUST parse as DNS if you want any hope of reliable delivery, PERIOD.

+1

> Rather, the client key MUST be contained in an EDNS resource record (this is exactly what EDNS is for!), and the response from the server MUST be completely encapsulated into an EDNS resource recor…

IMHO, this line of analysis is sound, valid, and strong.

I would propose that this analysis is valid for *any* proposal which
seeks to use a wire format which is does not conform to 103[45] or
2671 (or their successors).

Perhaps the WG can agree on advice for all new proposals, along the lines of:

Any proposal for changes to DNS wire format, must do so using EDNS
encapsulation, so as to ensure the following:
(a) backwards compatibility
(b) explicit per-new-type extended rcode support
(c) maximum likelihood of interoperability between implementations
including those which differ on specific EDNS components are
implemented/supported

Thoughts?

> As a consequence, DNSCurve should be rejected with extreme prejudice, and I mean extreme prejudice:

s/rejected.*:/morphed, or merged with the Barwood proposal./

+1

Brian

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Mar 2010 11:45:14 -0800

>> On port 53, you MUST parse as DNS if you want any hope of reliable delivery, PERIOD.

Also, as a corollary, if you want reliable delivery, you're going to want to use port 53, since there are many networks which block all UDP but a set of known ports/protocols.  So in the era of middleboxes, if you want to extend DNS, it needs to be port 53.

DNS does end up going through proxies, but the DNS format at least allows these proxies to pass unknown RRSets as opaque data, and at least it goes through (hopefully), unlike far too many other UDP ports.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Mar 2010 13:03:40 -0800

> Lets start with integrity, which what really counts in DNS:  The problem, simply put, is that any conventional threat analysis shows that link level integrity is almost useless:

I can't wait until we have HTTPSEC, which requires digital signatures
on every dynamically generated page.  After all, HTTPS's link level
integrity is almost useless.

> Against out of path attackers, we have robust defenses both universally implemented (port randomization), and proposed with some implementation (glue validation, 0x20, EDNS0-based).  Did we fail in this?

None of those protections are cryptographic.

> The problem is, simply put, DNS doesn't exist in a vacuum, DNS integrity is part of the final protocol.  And the final protocol either also trivially vulnerable to an in-path adversary, so DNScurve…

The same argument applies to DNSSEC.  E.g., web browsing is vulnerable
to in-path attackers unless you're using HTTPS instead of HTTP, and if
you're using HTTPS then whether or not you're using DNSSEC or plain
DNS doesn't improve your overall attack vulnerability.

> Worse, there is one in-path adversary that IS significant for DNS, because it is NOT on the final path for data: the recursive resolver!

Paul Vixie at least has stated he doesn't expect stub resolvers to
handle DNSSEC validation, so unless he's proven wrong, a DNSSEC
recursive resolver can still maliciously or unintentionally send bogus
responses to stub resolvers.

Regardless, the easy way to avoid this is to use a recursive resolver
you trust; e.g., if nothing else, a local resolver.

> Thus for DNS, traffic analysis will work wonders, ensuring that there is no real confidentiality except in rare cases.

That seems a silly argument.  Plain DNS and DNSSEC offer no
confidentiality at all.

> And really, the confidentiality risk is from the recursive resolver itself, eg, with some recursive resolvers (eg, Google Public DNS) really existing for the purpose of datamining the query stream.

Again, run your own recursive resolver then.

> Oh, and despite the obsession with reflector attacks, DNSCurve has no impact on this, because you can just do large response reflector attacks from open resolvers: DNSSEC's large replies actually p…

How many open recursive resolvers are there vs. how many authoritative
DNS servers?

> On port 53, you MUST parse as DNS if you want any hope of reliable delivery, PERIOD.

Can you back this argument?  Obviously packets that get sent to a DNS
forwarder need to parse as DNS, but reports I've read about home
network equipment are able to pass traffic to external hosts on port
53 just fine.

(Skipping responding to the rest of your arguments for now, since they
all seem to hinge on this claim.)

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Mar 2010 13:47:13 -0800

> Of course, if you are going to do this, you might as well also define keys in a resource record type as well, and gee, what do you get?  Well, something either like DNSSEC (if you use signatures on…

For what it's worth, I'm not against George Barwood's proposal.  My
feeling though is it's significantly more complex and will be harder
to gain adoption.  If DNSEXT is interested in adopting it instead of
or as well as DNSCurve, then I see nothing wrong with that.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 3 Mar 2010 18:05:43 -0400

> network equipment are able to pass traffic to external hosts on port

On both Cisco (PIX/ASA) and CheckPoint firewalls, current versions
have DNS inspection on by default. These not only require valid DNS
format, but track packets by query-id and require matches.

Note that in many environments, these firewalls may be present in
front of authority servers, as well as on egress for recursive and/or
stub resolvers.

This is likely to represent a significant portion of enterprise
environments, and thus, the DNS user base.

If there is an alternative approach that can be built with this in
mind, I think it best to use that design.

Brian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Mar 2010 14:19:00 -0800

>or as well as DNSCurve, then I see nothing wrong with that.

...which leads back to my original question of whether WG adoption means we can change part of the protocol, including what it does. I ask this because there are parts of DNSCurve that are inspired and useful (encoding a static ECDH key in the domain name of NS records) and others that are not (encrypting requests and responses).

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Mar 2010 17:24:00 -0500 (EST)

> integrity is almost useless.

Show me how a squid/transparent proxy can rewrite HTTPS traffic like a dnscurve recursor can?

> handle DNSSEC validation, so unless he's proven wrong

Paul Vixie will be wrong.

> you trust; e.g., if nothing else, a local resolver.

We agree there.

> That seems a silly argument.  Plain DNS and DNSSEC offer no

But to use the same arguments used against dnssec, "dnscurve adds too much complexity for too
little gain, as traffic analyses makes its privacy instantly useless.

> network equipment are able to pass traffic to external hosts on port

"just fine"? Perhaps you need to re-read the reports about DSL vendors? Changing
1 option bit in the DNS query packet caused the majority of routers to drop the
packet as invalid DNS packet.

See further:

http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf
http://www.dnssec-deployment.org/wg/materials/20071107/dnssec_incident_en.pdf (no longer
   available there. Does anyone have an alternative link? Jacob?)

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Mar 2010 14:32:02 -0800

> format, but track packets by query-id and require matches.

Additionally, this can be turned on even without administrator knowledge, as debugging with Netalyzr revealed.

Similar problems exist on end-user gateways: the number of gateways which refuse our deliberately non-bogus probe but do allow real DNS is shockingly high.

DNS in many ways is like HTTP:  Everyone HAS to support it to have a network connected "to the Internet", but a shockingly large fraction go through protocol-aware devices or proxies.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Mar 2010 14:35:05 -0800

> Show me how a squid/transparent proxy can rewrite HTTPS traffic like a dnscurve recursor can?

The point was squid can't cache HTTPS traffic, so you have to rely on
local caches.  Similarly, if you don't trust your DNS recursive
resolver, you can use a local cache that routes its DNS queries
directly to upstream resolvers.

HTTP is a much heavier weight protocol than DNS, and yet the Internet
survives with relying mostly on browser caches.

> "just fine"? Perhaps you need to re-read the reports about DSL vendors?

The bulk of that report is about problems with proxying DNS traffic.
Routing DNS traffic to upstream resolvers worked "just fine" as I
said.  See the first bullet point of the executive summary:

    All 24 units could route DNSSEC queries addressed to upstream resolvers
    (referred to herein as route mode) without size limitations.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Mar 2010 14:39:24 -0800

On Wed, Mar 3, 2010 at 2:19 PM, Paul Hoffman <[email-masked]> wrote:
> ...which leads back to my original question of whether WG adoption means we can change part of the protocol, including what it does.

And I already responded that yes, it does, as long as the resulting
protocol is able to coexist alongside the existing DNSCurve protocol
and uses a different name if it's not backwards compatible.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 3 Mar 2010 17:52:12 -0500

Dear colleagues,

I just want to remind everyone that, while there's nothing wrong with  
vigorous debate, we should all of us endeavour to keep that debate  
respectful.  Please be careful in your messages not to adopt an angry  
or sarcastic or attack-y tone. There is serious substance to debate  
here, and it'd be a shame if we lost the important stuff because  
people got angry.

Thanks!

A

-- 
Andrew Sullivan
<[email-masked]>

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Mar 2010 15:01:49 -0800

> integrity is almost useless.

And this is EXACTLY my point:  Who cares about in-path adversaries on the DNS when they can just packet inject a response for malicious Javascript.

This is exactly why I say "in path adversaries for DNS are largely irrelevant" (with the noteworthy exception of recursive resolver): either the protocol USING the DNS results is trivially p0wned by the same in-path adversary (HTTP) OR the protocol never trusted the DNS results (HTTPS).

Packet inject a DNS response to the query for "www.google-analytics.com" or packet inject a response for the "get /ga.js" request, and the results are the same: total p0wnage, because HTTP is trivially vulnerable to in-path adversaries.

Packet inject a DNS response to the query for "ssl.google-analytics.com" or packet inject a response for the "get /ga.js" request an the results are the same: epic fail, because HTTPS resists in-path adversaries, and a DNS poisoned response is no different from any other in-path adversary.

So for both cases, DNS's (in)security against in-path adversaries is effectively irrelevant, because as long as the adversary can also see the final traffic the results are the same.

Oh, and the internet does NOT survive under HTTP, its just nobody has bothered REALLY having fun with how browser caches work to cache bogus files, especially given the proliferation of WiFi networks and/or the fun you can have with ARP poisoning...

> None of those protections are cryptographic.

They are probabilistic.  Cryptographic protections are only probabilistic.  How many "bits of protection" do you want against out of path adversaries?  If your answer is "arbitrary", thats Barwood's EDNS0-ping.  If your answer is "32b or more", we got that today.  If your answer is "32b, no race until win", run Unbound.

> DNS doesn't improve your overall attack vulnerability.

This is why I also consider DNSSEC largely useless, except DNSSEC provides two huge conceptual features that DNSCurve does not, and one huge implementation feature:

Conceptual features:
a)  It offers protection against the recursive resolver's misbehavior, which is a significant problem in our experience with Netalyzr, both from deliberately malicious resolver settings and deliberate ISP manipulations (yes, Virginia, ISP's will man-in-the-middle google using DNS.  As does OpenDNS).

b)  It offers a "cheaper PKI", built along existing contractual relationships.

Technical advantage:
It can actually work on today's Internet, which is full of middleboxes which are especially hostile to non-DNS traffic on port 53

> responses to stub resolvers.

This is a mistake, and a huge one.  I have argued quite strenuously that it is the stub, NOT the recursive resolver, that must do the validation.

> you trust; e.g., if nothing else, a local resolver.

And THIS is why I argue that, by default, the stub should validate DNSSEC and, regardless of failure mode, generate an independent iterative request and blindly accept it, at least for the default gethostbyname API.

> That seems a silly argument.  Plain DNS and DNSSEC offer no

No confidentiality vs almost none:  DNSCurve provides hardly ANY practical confidentiality in the face of traffic analysis, so why mention it at all?  IN fact, I'd have security considerations be for confidentiality:

"Since traffic analysis still sees both the authority and requester, and the size of the request and reply, and the frequency of the requests and replies, and can probably generate its own requests to the authority, it is expected that DNSCurve provides very little confidentiality when compared with unencrypted traffic"

> How many open recursive resolvers are there vs. how many authoritative

hundreds of thousands.  3%+ of Netalyzr uses are open DNS proxies!  You just scan the net randomly and you get a ton.  All the amplification sources you want, in the palm of your hand.  Who needs DNSSEC authorities when you can just query for . across the net?  OR better yet, "Attacker's big bloated well cached txt record"?

> network equipment are able to pass traffic to external hosts on port

Actually, our experience is the opposite.  Netalyzr does a deliberately bogus (non DNS) UDP request to our server bookened by two legitimate requests.  The fraction of gateways that block this is disturbingly high, over 10%.

Also, as mentioned elsewhere, there are MANY firewalls that parse DNS and reject invalid DNS, we experienced this personally with colleagues who, during Netalyzr testing, went "Uhh, your wrong, our net doesn't do anything to DNS", before coming back to us later saying "Oh, you were right, our XYZ firewall parses DNS and rejects invalid datagrams".

Especially since the "No EDNS, 512B limit" inherent in DNSCurve's default design objective is derived from a misidentification of the problem: The network doesn't dislike packets >512B with UDP, it dislikes DNS PACKETS which are >512B, because a middlebox is rejecting such DNS as "invalid".  If it rejects DNS over 512B, what do you think it will do to a "DNS" request thats completely novel and unparsable as DNS?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Mar 2010 10:44:34 +1100

In message <[email-masked]>, Nicholas W
eaver writes:
> This is exactly why I say "in path adversaries for DNS are largely =
> irrelevant" (with the noteworthy exception of recursive resolver): =
> either the protocol USING the DNS results is trivially p0wned by the =
> same in-path adversary (HTTP) OR the protocol never trusted the DNS =
> results (HTTPS).

The internet isn't just http/s.

> >=20
> >> Worse, there is one in-path adversary that IS significant for DNS, =
> because it is NOT on the final path for data: the recursive resolver!
> >=20
> This is a mistake, and a huge one.  I have argued quite strenuously that =
> it is the stub, NOT the recursive resolver, that must do the validation.

Actually both the recursive resolver and the application/stub should be
validating.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Mar 2010 08:06:53 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Wed, 3 Mar 2010 09:15:28 -0800
> ...

i don't know if i'd go quite that far -- and in fact, i didn't:

http://www.isc.org/community/blog/201002/whither-dnscurve

---

From: [email-masked]
Date: Thu, 4 Mar 2010 08:15:10 +0000

> network equipment are able to pass traffic to external hosts on port

I can back this argument, although it's not clear whether by "pass" you 
mean "route", or "proxy" or both.

Most will indeed _route_ DNS packets quite happily.  Also, some home boxes 
do just proxy the packets with minimal or negligible parsing.  If DNSCurve 
leaves the DNS header format alone it should get through those with 
minimal problems.

However many of the home gateways are effectively forwarders which _do_ 
parse the packets, but fail to do so correctly.  Many of those boxes in 
turn provide no way to override the DHCP-offered DNS server settings.  The 
default behaviour on a home LAN using one of those devices is to proxy, 
rather than route, with no way other than manual reconfiguration of the 
client to change it.

Ray

---

From: [email-masked]
Date: Thu, 4 Mar 2010 08:20:04 +0000

>     (referred to herein as route mode) without size limitations.

[see previous reply].

_route_ traffic, yes.  Your previous message was ambiguous, though.  You 
originally said "pass", which might imply "route" _or_ "proxy".

Unfortunately firmware issues mean that many end users are unaware of 
whether they're in "route" or "proxy" mode.

Ray

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2010 17:30:28 +0900

[email-masked] wrote:

> parse the packets, but fail to do so correctly.

And they make deployment of DNSSEC impossible. Right?

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Thu, 04 Mar 2010 08:32:47 +0000

* Nicholas Weaver:

> b) DNSCurve's implementation guarantees substantial deployment
> problems due to transport issues, because it doesn't parse as DNS
> and never considered why 512B is a "magic number" for DNS on the
> network.

But this part can be addressed trivially by using a different port.

-- 
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: [email-masked]
Date: Thu, 4 Mar 2010 08:48:30 +0000

> And they make deployment of DNSSEC impossible. Right?

No, not really.

If the stub resolver does _not_ do validation, then there are two cases:

1.  dumb stub, talking to validating resolver - no issue, since the client 
will just get SERVFAIL on validation failure

2.  DNSSEC aware stub - minor but rare issues, due to the relatively few 
units which drop request packets with DO=1, or responses with AD=1.

If the stub resolver _does_ do validation, then the problems may be worse 
if going through such a forwarder, because then the response-length issues 
come into play.

However if the stub resolver can be configured to bypass the proxy / 
forwarder and _route_ the packets directly to the upstream recursor then 
most of the problems should disappear.  Auto-configuration of stub 
resolvers to achieve that is the aim of 
draft-bellis-dns-recursive-discovery-00, currently stalled waiting for a 
call for WG adoption in DNSOP.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Mar 2010 09:45:22 +0000

> Date: Wed, 3 Mar 2010 17:24:00 -0500 (EST)
> From: Paul Wouters <[email-masked]>
> 

i (paul vixie) am actually hoping to be wrong about this.  however, stub
validation counts on dnssec awareness in the recursives and edns
transparency in the NATs and firewalls... which is "a tall order".

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2010 22:10:17 +0900

> No, not really.

See below.

> most of the problems should disappear.

I'm afraid that the point against other proposals was that it is
too often impossible to bypass the proxy / forwarder (and/or a
firewall), against which I have no objection.

You can't do much against your upstream. PERIOD.

Thank you for confirming that deploying DNSSEC is impossible.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Thu, 4 Mar 2010 12:11:35 -0500 (EST)

>    (referred to herein as route mode) without size limitations.

DHCP generally is up and ready before the uplink of the device is. This
is the whole reason for there being a proxy DNS server on the units. So
that it can just punt (I can't call it "forward") to the uplink's obtained
DNS server via DHCP there.

All 24 units could route DNSSEC translates to "It is broken to the enduser, unless
they manually select a DNS server every time they enter another (wifi) network".

If that's a dnscurve requirement, it is obviously not ready for real deployment. The
DNSSEC community has been talking to vendors for two years to fix that. You'd have
to go through the same for dnscurve (especially because its even more incompatible
with the format of DNS packets from 10 years ago). As others pointed our, you're
better of moving away from port 53.

Paul

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 20:04:00 -0800

> integrity is almost useless.

You're conflating two entirely different elements of SSL certificates 
used for https. The encryption between endpoints is not what gives the 
"integrity" that most people care about when they think about https. 
What people care about is, "When I connect to 
https://www.retailer.example/ and enter my credit card information am I 
connecting to the REAL retailer, or is it a hacker?" Their sense of 
confidence is established by the fact that the certificate on the web 
server they are connecting to is validated by a trusted 3rd party 
authority (as represented by the ca-root certs in their browser). In my 
mind this trust relationship more closely resembles dnssec than it does 
dnscurve.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 5 Mar 2010 13:43:38 -0500 (EST)

>> It sounds extremely inefficient and complex.

And missing features that RFC 4025 already has, such as precedence and using
a machine different from the target machine as IPSEC gateway.

Paul

---

From: Federico Lucifredi <[email-masked]>
Date: Fri, 12 Mar 2010 03:12:53 -0500

I have been meaning to get to your draft George... sorry, I am swamped.
But I do plan to do a detailed reading as soon as I have a minute.

 Best -F