Subject: [dnsext] a note on the discussion about DNSCurve and DNSSEC

From: "Roy Arends" <[email-masked]>
Date: Fri, 5 Sep 2008 12:04:21 +0200

I think it is safe to assume that though DNSSEC and DNSCurve have some 
overlap in functionality, both try to solve different problems. They are 
not mutually exclusive, there does not need to be a choice. There is no 
need, IMHO, to go into polarizing debates about functionality, or lack of 
functionality. May I suggest that we wait for an internet-draft, some 
running code for DNSCurve and some rough consensus? Personally, I would 
appreciate it if DNSCurve could stand on its own, without clinging to 
perceived deficiencies of DNSSEC.

After all, this mailing list is an IETF based list, open to all who are 
willing to contribute (positively). It would be so much more productive if 
we can test interoperability between various DNSCurve implementations; 
Build those implementations on a sound specification, and that the 
specification comes in a form we are comfortable with: an internet-draft.

Such an internet-draft (or set of internet drafts) would most likely need 
to include a problem statement, a set of requirements, an introduction to 
the proposed solution, etc.

Without such, we're wearily debating in circles, stalling process on 
standardization of these solutions. Lets not continue this modus operandi.

Regards,

Roy Arends
Nominet

--
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: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 05 Sep 2008 09:25:00 -0400

Thank you Roy, for your excellent message.

WG: the chairs think this is an excellent path to follow.

The chairs encourage the creators of DNScurve to bring any documentation or
requirements to the working group for either formal or informal discussion.

         Olafur & Andrew

---

From: "Jon A. Solworth" <[email-masked]>
Date: Fri, 05 Sep 2008 09:02:12 -0500

Roy Arends wrote:
> overlap in functionality, both try to solve different problems. 
    I agree completely.  DNSCurve has different design goals than
DNSSEC.  I think of DNSCurve as a very conservative "lets fix the
problems of network attacks against DNS protocol".  Its conservative
in the sense that it tries not to introduce new issues which might
have unforeseen implications.

    DNSSEC is more ambitious.  It says sign the DNS records offline
and then as long as the root public keys are OK, DNS records are
tamperproof.

> They are 
> not mutually exclusive, there does not need to be a choice.
   I agree that these are mutually exclusive.  DNSCurve gives anti-DDoS
protections which can be combined with DNSSEC's stronger integrity
guarantees.

>  There is no 
> functionality. 
     Why should a technical discussion be polarizing?   As Paul pointed out,
these discussions take time, so it seems that early discussion of DNSCurve
is advantageous.
> May I suggest that we wait for an internet-draft, some 
         Perhaps I'm misunderstanding what you intended, but it sounds
like your suggestion is that wait to discuss that until we have consensus
(and running code). 

    How are we going to get consensus without discussion?

    Would it not be good to understand a basis for evaluation before the
    code exists?

    Frankly, I think this problem is too important to be back-burnered.

-- 
______________________________________________________________________________
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: Eric Rescorla <[email-masked]>
Date: Fri, 05 Sep 2008 07:47:15 -0700

At Fri, 05 Sep 2008 09:25:00 -0400,
> requirements to the working group for either formal or informal discussion.

I think requirements are probably what's most appropriate here.

At a high level, there are two general architectural approaches that
can be taken to this problem: object security and channel security,
with DNSSEC being an example of the former and DNSCurve being an
example of the latter.

If there's general agreement that the IETF should pursue a channel
security approach as well, then it's reasonable to discuss what
the properties of that channel security protocol ought to be and
how best to fill that gap. We already have a lot of experience
with designing such protocols and it's not at this point clear
to me that we need an entirely new one. 

-Ekr

---

From: [email-masked]
Date: Fri, 5 Sep 2008 15:10:28 +0000

On Fri, Sep 05, 2008 at 07:47:15AM -0700, Eric Rescorla wrote:
> Slafur Gupmundsson /DNSEXT chair wrote:
> > 

	given that the IETF did TSGI and SIG(0) and TSIG and SIG(0) are 
	both methods for channel security(#), it seems reasonable to 
	consider other methods for channel security within the IETF.

# can we use the more accurate wording here?  what we are really after
is integrity of the channel, not any of the other attributes of the "security"
umbrella.

--bill

---

From: "Roy Arends" <[email-masked]>
Date: Fri, 5 Sep 2008 17:33:52 +0200

"Jon A. Solworth" <[email-masked]> wrote on 09/05/2008 04:02:12 
PM:

>      Why should a technical discussion be polarizing?

I agree that merely having a discussion on the technicalities of a single 
proposal would not have to be polarizing. However, I noticed a trend 
towards DNSSEC versus DNSCurve, which is comparing apples to oranges, an 
easy trap for polarization. I noticed some guess work by the interested, 
followed by some punters by the informed. 

> like your suggestion is that wait to discuss that until we have 
consensus

My suggestion is to wait with a discussion about DNSSEC versus DNSCurve 
until we need to. I am more than supportive of a good discussion on the 
functionality, usefulness and design of DNSCurve itself, but see my point 
below.

>     How are we going to get consensus without discussion?

How can we discuss a solution without a problem statement? A specification 
that includes a problem statement would help me discuss a solution. A 
general problem statement would also help other suggested "channel" or 
"transaction" solutions qualify. These solutions can be DJB's Nym-based 
security, DNSCurve or his proposal at UVA last year, Duane's DNS 
Encryption proposal, a DTLS based solution, extending TSIG/SIG(0) to 
include encryption, etc, etc.

Regards,

Roy

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 05 Sep 2008 16:47:25 +0100

On Fri, 05 Sep 2008 15:02:12 +0100, Jon A. Solworth  
<[email-masked]> wrote:

> (and running code).     How are we going to get consensus without  
> discussion?

	As I read his message, Roy seemed to be suggesting that an
	initial draft would help focus the discussion.  This would
	be an expression of encouragement, rather than the opposite.

	Best regards,

	Niall

---

From: Francis Dupont <[email-masked]>
Date: Fri, 05 Sep 2008 17:49:35 +0200

In your previous mail you wrote:

=> and please note we already have TSIG and its associated protocols
(TKEY, RRSIG(0), ...).

Regards

[email-masked]

PS: as I wrote because of the caching & no-trust infrastructure of the DNS
what we need first is what you call the "object security".

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 05 Sep 2008 09:04:31 -0700

At Fri, 5 Sep 2008 17:33:52 +0200,
> include encryption, etc, etc.

I'd like to see some explanation of why people believe confidentiality
is particularly important in this context.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Sep 2008 09:05:48 -0700

At 9:02 AM -0500 9/5/08, Jon A. Solworth wrote:
>>  There is no need, IMHO, to go into polarizing debates about 
>>functionality, or lack of functionality.

I take it you are new to the IETF, then. :-) I'm sure Dan can point 
you to some archives of technical discussions with which he is 
familiar that could be described as "polarized".

>>May I suggest that we wait for an internet-draft, some running code 
>>for DNSCurve and some rough consensus? Personally, I would 
>>appreciate it if DNSCurve could stand on its own, without clinging 
>>to perceived deficiencies of DNSSEC.
>>

It doesn't sound like that at all. The request for an Internet Draft 
is so that the full proposal for the protocol can be considered. At 
this point, we don't even have a protocol diagram, much less a 
description of what information is carried on the wire.

>    How are we going to get consensus without discussion?

A more apropos question is "how are we going to have a useful 
discussion without a clear and complete first draft of the proposal"?

>    Would it not be good to understand a basis for evaluation before the

Yes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 5 Sep 2008 09:35:27 -0700

> what we need first is what you call the "object security".

More precisely:

For purposes of insuring integrity in a distributed, cache-based  
architecture such as DNS, channel integrity is strictly less powerful  
than object integrity.

Object integrity can protect objects in the channel as well as the cache

Channel integrity can not protect objects in the caches

For purposes of deployment, both channel integrity and object  
integrity schemes have many of the same problems, including developing  
and using a trust/key-distribution mechanism and very limited benefits  
from partial deployment.

For purposes of protecting confidentiality on the wire, Object  
integrity offers no protection, but in the face of traffic analysis,  
channel confidentiality offers very little protection.

For purposes of protecting confidentiality at the cache, neither  
mechanism offers protection.

---

From: "Jon A. Solworth" <[email-masked]>
Date: Fri, 05 Sep 2008 11:46:52 -0500

> familiar that could be described as "polarized".
    I may have seen something to that effect :-)   I hope I have not 
been polarizing,
and in fact it has been my purpose to get people together, and to find 
the speediest
way to get authenticated information on the Internet.  I think the 
issues are too
important.

    I think that DJB wants to follow a model of implementation precedes 
standardization;
given this model a standards document would be premature.  But the 
suggestion of
an informal presentation to IETF is interesting.

Jon

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Sep 2008 09:54:56 -0700

At 11:46 AM -0500 9/5/08, Jon A. Solworth wrote:
>    I think that DJB wants to follow a model of implementation 
>precedes standardization;

Just to be clear: I didn't suggest that. I agreed with the others who 
have said than an Internet Draft describing the protocol is the 
appropriate way forwards if you want DNSCurve to be discussed in the 
IETF.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Sep 2008 10:05:15 -0700

>=> and please note we already have TSIG and its associated protocols

To be fair, it is clear from the discussion that DNSCurve describes a 
way to scalably produce and distribute the keying material needed for 
something like TSIG. TSIG without something like DNSCurve is like 
IPsec without IKE

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 5 Sep 2008 09:35:27 -0700

More precisely:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 05 Sep 2008 10:27:29 -0700

At Fri, 5 Sep 2008 09:54:56 -0700,
> appropriate way forwards if you want DNSCurve to be discussed in the 

FWIW, I agree with Paul here. Without taking a position on the merits
one way or the other of "implementation precedes standardization", if
you want the IETF to consider this technology then really the first
thing to do is to write an I-D describing it.

-Ekr

---

From: Jefferson Ogata <[email-masked]>
Date: Fri, 05 Sep 2008 17:45:07 +0000

On 2008-09-05 16:35, Nicholas Weaver wrote:
> For purposes of protecting confidentiality on the wire, Object integrity
> offers no protection, but in the face of traffic analysis, channel
> confidentiality offers very little protection.

Not by itself, but object integrity allows the two parties to publish
keys for one another in order to establish confidentiality using an
encryption layer built on top of DNS.

For example, a zone that provides confidentiality can publish a public
key as a DNSSEC RR. Someone who wants to query that zone can encrypt the
query to that public key, and include with the query the FQDN of another
public key, also published in a DNSSEC RR, for the reply to be encrypted
to, providing confidentiality in both directions.

-- 
Jefferson Ogata : Internetworker, Antibozo