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
At 06:04 05/09/2008, Roy Arends wrote:
>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 namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
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
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.
=> and please note we already have TSIG and its associated protocols
(TKEY, RRSIG(0), ...).
Regards
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".
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.
>>
> 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).
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
> code exists?
Yes.
--Paul Hoffman, Director
--VPN Consortium
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.
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