Subject: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Oct 2005 18:10:44 -0400

Dear all:

We are pleased to announce the release some software tools for DNSSEC
Trust Anchor Key rollover. You may download from

http://www.connotech.com/takrem_tools/trust-anchor-foundry_01.tar.gz

This is a first step towards facilitating TAKREM deployment a practical 
solution for DNSSEC automated trust anchor key rollover (draft 
draft-moreau-dnsext-takrem-dns-00.txt).

The emphasis has been put on documenting the software design issues and 
providing a workable software base (GPL'ed free software).

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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: Paul Vixie <[email-masked]>
Date: Sat, 29 Oct 2005 05:26:02 +0000

isn't TAKREM based on patent-protected IPR?

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Oct 2005 23:18:23 -0700 (PDT)

> isn't TAKREM based on patent-protected IPR?

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=640

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Ben Laurie <[email-masked]>
Date: Sat, 29 Oct 2005 14:06:23 +0100

> isn't TAKREM based on patent-protected IPR?

That is my understanding.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Paul Vixie <[email-masked]>
Date: Sat, 29 Oct 2005 14:54:59 +0000

to this:

# > isn't TAKREM based on patent-protected IPR?

i recieved two replies:

# From: "william(at)elan.net" <[email-masked]>
# 
# https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=640

and:

# From: Ben Laurie <[email-masked]>
# 
# That is my understanding.

it is therefore my plan, and my recommendation to others, to ignore TAKREM, to
not evaluate the specific proposal nor the tools, and to oppose its adoption
as an Internet standard of any kind.  it is my advice to Thierry Moreau that
all work toward supporting DNSSEC with this technology be stopped.

(note: i don't have any hats.)

---

From: Ben Laurie <[email-masked]>
Date: Sat, 29 Oct 2005 18:29:59 +0100

> (note: i don't have any hats.)

FWIW, I agree.

---

From: Matt Larson <[email-masked]>
Date: Sat, 29 Oct 2005 17:17:53 -0400

> > (note: i don't have any hats.)

And I further agree.  I had already been ignoring TAKEM because of the
patent holder's heretofore inability to produce an IPR statement and
his apparent evasiveness on that topic.  DNSSEC has enough of an
uphill deployment hurdle without throwing in patent-encumbered
technology.  (Although IANAL, the posted license terms are
unacceptable to VeriSign.)

Matt
--
Matt Larson <[email-masked]>
VeriSign Naming and Directory Services

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 30 Oct 2005 00:48:50 +0200 (CEST)

Until TAKREM is free to implement and use for DNSSEC (without 
restrictions), I believe it should be ignored.

my suggestion is to move forward with a combination of Johan Ihrén's 
n-of-m proposal and Mike StJohns' revoke-bit.

 	jakob

---

From: Ben Laurie <[email-masked]>
Date: Sun, 30 Oct 2005 16:24:35 +0000

Jakob Schlyter wrote:
> n-of-m proposal

Isn't that also encumbered?

> and Mike StJohns' revoke-bit.

Dunno the status of this, IP-wise.

---

From: [email-masked]
Date: Sun, 30 Oct 2005 16:29:52 +0000

> Dunno the status of this, IP-wise.

	both of these proposals have been tagged by the diversinet
	patent.  that patent was issued in Israel, filed and withdrawn
	in Europe, filed in Canada, extended twice (still not issued)
	... my legal council indicated that since the m/n work was 
	based on the SET work, that we could proceed w/ a reference
	implementation, as long as the work was not done in Israel.
	Not that the IETF cares of course.

--bill

> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <[email-masked]>.
> To unsubscribe, E-mail to: <[email-masked]>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/>

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 31 Oct 2005 11:55:42 -0500

Dear all:

Some participants indicated their reluctance to study the draft
draft-moreau-dnsext-takrem-dns-00.txt on the basis of IPR issues,
presumably on the basis of other solutions, less encumbered by
IPR issues, for the technical problem at hand, i.e automated
trust anchor key rollover procedures.

If there was a clear problem statement with some consensus on the
technical requirements, it might be acceptable to state that
"solution A" meets these requirements and the IETF DNSEXT wg is
satisfied.

However, the problem statement and the technical requirements for
an automated trust anchor key rollover scheme are not well
established. Part of the proposal being ignored address this
aspect of the DNSEXT wg activities.

Moreover, the RFC3979 section 8 assigns a discretion to IETF wg
to adopt a technology in the presence of IPR claims, based on an
economic analysis, i.e. if the wg finds "that this technology is
superior enough to alternatives with fewer IPR claims or free
licensing to outweigh the potential cost of the licenses."

Having this discretion and the mandate to solve the trust anchor
key rollover problem, the DNSEXT wg should determine that the IPR
encumbered technology is *not* superior enough. If those who are
strict in their reluctance to study the
draft-moreau-dnsext-takrem-dns-00.txt are convinced that this is
the inescapable outcome of the wg activities, they merely decline
to participate in progress towards this determination.

In summary, I suggests that in the absence of a clear problem
statement with some consensus on the technical requirements,
abstaining from a review of the draft
draft-moreau-dnsext-takrem-dns-00.txt is potentially introducing
delays in the DNSEXT wg progress.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Ben Laurie <[email-masked]>
Date: Mon, 31 Oct 2005 16:56:28 +0000

> to participate in progress towards this determination.

Since key rollover will be mandatory, this statement applies:

  "An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so. "

So, until we have determined that there is no IPR-free route to solving
the problem, there is little point in reviewing the I-D. Thanks for
pointing this out, I should've read it sooner.

I suppose at this point I should remind people that my key distribution
I-D
(http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.txt)
could also be used for key rollover, probably with only minor changes,
and has not, so far, had any IPR claims against it.

Cheers,

Ben.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 31 Oct 2005 09:21:07 -0800

Dear colleagues,

Since we have addressed all formal  RFC3979 issues I think that we  
should get actual work done.

I think Thierry has a point when he refers to the requirements.  
Making the now implicit requirements more explicit is probably a good  
step for a work item where we have multiple authors each promoting  
their own ideas.

Any volunteers that want to start compiling the requirements. Making  
a start by enumerating those on the list is probably a good idea. We  
can see later if we want to cast them into an I-D or make them an  
integral part of the specification. (Casting requirements into an I-D  
has proven difficult at times)

Having a first iteration by Monday next week might actually be useful.

Any takers???

I'd prefer somebody that does not have their name on one of the  
drafts.  Please let me and Olafur know off-line if you want to take  
up this work.

--Olaf

PS: I posted this to Namedroppers only, this is about IETF process.

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 31 Oct 2005 13:00:18 -0500 (EST)

> delays in the DNSEXT wg progress.

One might also argue that introducing a draft with known IPR issues
also delays the process.

Like many others, I'm reluctant to spend more time on this draft
due to its IPR issues.

That said, my review of the description posted to the
dnssec-deployment list over the summer led me to think that there's
nothing superior in this technology.  I wrote:

> First, the idea of prepublishing public keys (or hashes of them) has
> been discussed in the DNSSEC community for quite some time.
> ...
> The idea of using MASH's rather than an unparameterized hash
> function may be new in this community, but I'm not sure it adds
> sufficient value over using a strong non-parameterized hash
> function.

-- Sam