Subject: RE: RFC2672bis DNAME update document

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 12 Jun 2006 11:21:31 -0400

Seems like a good idea to me.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ólafur Guðmundsson /DNSEXT co-chair
Sent: Monday, June 12, 2006 10:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: RFC2672bis DNAME update document

The chairs have recruited volunteers to take on this effort They are:
	Matt Larson <[email-masked]>
	Wouter Wijngaards <[email-masked]>

Right now they are working on assembling a list off issues, related to RFC2672 DNAME specification. If you have issues/experiences with DNAME that you would like to see in the initial list of issues, please send them a note, right now.

We need 5 people that speak up in response to this note and between those people there is general consensus that this document is a work item, If we do not consensus, we will ask the editors to post this document as a personal submission first.
(We'd be sad if that would need to be the case.)

The editors will operate an public issue tracker for the document.

The process is a standard clarify process: Wouter and Matt are editors reflecting the consensus of the working group.

The initial time line for this effort is to try to have the working group finish this with this document by IETF 68 (March/2007).
At this point it is not clear if the resulting document will be recycled at Proposed or be issued as a Draft standard.

	Olafur & Olaf 

--
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: David Blacka <[email-masked]>
Date: Mon, 12 Jun 2006 17:21:57 -0400

On Jun 12, 2006, at 10:35 AM, Ólafur Guðmundsson /DNSEXT co-chair wrote:

>
> We need 5 people that speak up in response to this
> note and between those people there is general consensus that this
> document is a work item, If we do not consensus, we will ask the
> editors to post this document as a personal submission first.

Just removing the references to EDNS1 would be a big improvement, IMHO.

So, I certainly support this becoming a work item.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Mike StJohns <[email-masked]>
Date: Mon, 12 Jun 2006 17:42:02 -0400

Olafur -

While I don't have any problems with this as a 
work item, I will note that we haven't made very 
much progress on those already on our plate.  I'd 
like to suggest deferring this for one meeting 
with the hope that the chairs will do some much 
needed spring cleaning of the groups current tasks.

Mike

At 10:35 AM 6/12/2006, Ólafur Guðmundsson /DNSEXT wrote:

>Right now they are working on assembling a list off issues,
>related to RFC2672 DNAME specification. If you have
>issues/experiences with DNAME that you would like to see in the
>initial list of issues, please send them a note, right now.
>
>The process is a standard clarify process: Wouter and Matt are editors
>reflecting the consensus of the working group.
>
>The initial time line for this effort is to try to have the working
>group finish this with this document by IETF 68 (March/2007).
>At this point it is not clear if the resulting
>document will be recycled at Proposed or be issued as a Draft standard.
>
>         Olafur & Olaf
>
>--

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Jun 2006 09:05:06 +1000

The TTL of the synthesised CNAME is currently set at zero.
	There is no reason not to make the TTL of the CNAME match
	the TTL of the DNAME.  Doing so will reduce the load on
	the authoritative servers from non DNAME aware clients
	by allowing them to cache the CNAME name.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olaf M.Kolkman <[email-masked]>
Date: Tue, 13 Jun 2006 15:22:31 +0200

On Jun 12, 2006, at 11:42 PM, Mike StJohns wrote:

> Olafur -
>
> While I don't have any problems with this as a work item, I will  
> note that we haven't made very much progress on those already on  
> our plate.  I'd like to suggest deferring this for one meeting with  
> the hope that the chairs will do some much needed spring cleaning  
> of the groups current tasks.
>

Hello Mike,

Let me try to focus on that other, very important piece of work that  
has taken far to long to produce output; trust-anchor management.

I want to try and get requirements done before the next IETF. Suresh  
has identified a few final issues and is about to post (or has  
posted, I have not cleared my inbox yet) a rev of the document. That  
version I'd like to last call.

The requirements (finally) provide us a means to select among  
proposals. But in order to make that selection we do need folk that  
are committed to do some work in this space.

I propose the following.

1 - All editors off drafts make sure that their drafts are alive in  
the repository. (before start of summer, June 21)

2 - Maybe some editors want to revoke their draft in lessen the  
entropy in this space or just because they think another draft is  
superior

3 - We start a reading round of one month. Here we need working group  
participants doing real work (!). I would like to see (at least 5?)  
people to read _all_ the drafts. (before IETF meeting (?))

4 - While reading drafts reviewers create issue lists

5 - All people that read _all_ drafts (hopefully more than 5) will  
provide their motivated preference, say a top 3. Motivation is to be  
based on requirements. (There are folk who did proposal comparison.  
It would be good if those were reviewed and reposted at that time).

6- We compile a shortlist of 1 or 2 documents and work to technically  
improve those to get a consensus outcome.

I am hesitant to spend to much face-2-face time on rehashing previous  
discussion. But if we manage to have some review done, issues  
identified, and preferences stated, we may actually be able to make  
real progress.

I'd say that committed reviewers need anything between 1 to 3 days to  
do this work.

Any comments, alternative approaches, takers?

--Olaf

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

---

From: Gustavo Lozano <[email-masked]>
Date: Mon, 26 Jun 2006 11:05:02 -0500

Olaf,

I want to know what the status of this proposal is.

Do some drafts were revoked by the authors?

Thank you.

>Any comments, alternative approaches, takers?

gus

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 27 Jun 2006 09:52:12 +0200

> I want to know what the status of this proposal is.

Gustavo,

Thanks for asking, you are the first person that makes me sure that  
my mail did not hit everybody's spam filter.

In a separate thread the other week I posted a proposal.

> entropy in this space or just because they think another draft is

What we have is currently, without having talked to any of these folk:

Expired: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext- 
trustupdate-threshold
I am not sure what Ihren and Manning would like to see happening to  
this proposal.

About to expire: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext- 
trustupdate-timers
I work from the assumption that this is one of the (promising[*])  
candidates

And from individuals we have:
draft-laurie-dnssec-key-distribution-02.txt

Finally there is Thieries work:
http://tools.ietf.org/wg/dnsext/draft-moreau-dnsext-takrem-dns-02.txt

Note that this document (version 2) now has a "Derivative Works  
Limitation" given RFC3978 that excludes it from becoming a working  
group document. That also means that it is reasonable to not expect  
people to put any effort into reviewing and improving it. I am not  
sure what the procedure is when people want to run with version 1 of  
the document that was less restrictive. If people think then takrem  
is the best technology after sliced bread and it should be considered  
for working group adoption than feel free to post that on the list,  
we can either work with the author or sort out if it is possible to  
go from version 1.

DLV is not on the table as far as I am concerned.

In practice this means that we have 3 documents to consider.

> It would be good if those were reviewed and reposted at that time).

Note that Alberto Martínez Herrera's comparison is still available at:
http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf

I recall there is a second comparison but I cannot find it.

Still we new more reviewers. By having people comment and choose on  
proposals we can get forward progression.

> Any comments, alternative approaches, takers?

As I am trying to come up with a reasonable way to pick up forward  
momentum, this is still an open question: comments, alternatives,  
takers?

---Olaf

[*] oops .. there goes your neutral chair.

---

From: [email-masked]
Date: Tue, 27 Jun 2006 12:18:37 +0000

> I am not sure what Ihren and Manning would like to see happening to  

	i expect that, based on feedback from the last IETF mtg, there
	is no interest in this work by the WG. That said, i think this
	work is perhaps the best way forward - at least for my vision
	of how the DNS should evolve.  That said, i will continue to 
	work on this.

> http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf

	i was never able to read this...

---

From: Sam Weiler <[email-masked]>
Date: Tue, 27 Jun 2006 08:45:47 -0400 (EDT)

> DLV is not on the table as far as I am concerned.

Why is that?

I'd like to see the WG members review DLV to see what, if any, 
problems it may help address -- that may help us scope the work we 
want to take on within DNSEXT.

For those not already aware, there is a DLV draft in the i-d 
repository:  draft-weiler-dnssec-dlv-00.txt Version 01 has been 
submitted and should appear before the meeting in Montreal.  I welcome 
comments on the document.  ISC also published a tech note that 
purports to describe their implementation.  As far as I know, no one 
has claimed any encumbrance on the technology.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 27 Jun 2006 15:01:53 +0200

>> DLV is not on the table as far as I am concerned.

Because I thought nobody put it on the table for solving trust-anchor  
rollover (I may be wrong). Wouldn't you agree that also with DLV you  
need to have a mechanism to roll te DLV anchor?

--Olaf

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 27 Jun 2006 15:43:40 +0200

Note that "to table" has different meanings in different parts of
the world. In the US, it is basically putting it to rest, while in
the more Anglo Saxion parts it is meant to put for consideration.
I think that Olaf uses the latter meaning while Sam might mean the
first. Maybe we should not use the term at all.

	jaap

PS: See: http://en.wikipedia.org/wiki/Table_%28verb%29

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Jun 2006 09:50:26 -0400

At 15:01 +0200 6/27/06, Olaf M. Kolkman wrote:

>rollover (I may be wrong). Wouldn't you agree that also with DLV you need
>to have a mechanism to roll te DLV anchor?

I'd have to say no..."shockingly."

DLV is being touted as a "temporary, non-scaleable hack" to jump 
start DNSSEC adoption.  As such, long range considerations are not 
mainstream.

Although ... on http://www.nanog.org/mtg-0606/damas.html it does 
mention DLV as a trust anchor management (avoidance) tool.

I'm postulate that DLV is trying to be the 6Bone of IPv6.  Perhaps 
the last DLV will expire on 6/6/6 (as in 3006). ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Robert Story <[email-masked]>
Date: Tue, 27 Jun 2006 14:16:42 -0400

On Tue, 27 Jun 2006 15:43:40 +0200 Jaap wrote:
JA>     > On Tue, 27 Jun 2006, Olaf M. Kolkman wrote:
JA>     >
JA>     >> DLV is not on the table as far as I am concerned.
JA>     >
JA>     > Why is that?
JA>     
JA>     Because I thought nobody put it on the table for solving trust-anchor  
JA>     rollover (I may be wrong). Wouldn't you agree that also with DLV you  
JA>     need to have a mechanism to roll te DLV anchor?
JA>     
JA> Note that "to table" has different meanings in different parts of
JA> the world. In the US, it is basically putting it to rest, while in
JA> the more Anglo Saxion parts it is meant to put for consideration.

It's a little more complicated than that.

"to table" is to delay. e.g. "We're going to table that decision until
we have more information.

"on the table" is something under consideration.

"off the table" is something that is not under consideration.

-- 
Robert Story
SPARTA

---

From: Ben Laurie <[email-masked]>
Date: Wed, 28 Jun 2006 02:28:13 +0100

Olaf M. Kolkman wrote:
> Thanks for asking, you are the first person that makes me sure that my
> mail did not hit everybody's spam filter.
> 
> Expired:
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-threshold
> I am not sure what Ihren and Manning would like to see happening to this
> proposal.
> 
> About to expire:
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers
> Limitation" given RFC3978 that excludes it from becoming a working group
> document. That also means that it is reasonable to not expect people to
> put any effort into reviewing and improving it. I am not sure what the
> procedure is when people want to run with version 1 of the document that
> was less restrictive. If people think then takrem is the best technology
> after sliced bread and it should be considered for working group
> adoption than feel free to post that on the list, we can either work
> with the author or sort out if it is possible to go from version 1.
> 
> momentum, this is still an open question: comments, alternatives, takers?

Well, I guess I'm a taker if there's any interest in my approach.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"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: Ben Laurie <[email-masked]>
Date: Wed, 28 Jun 2006 02:30:38 +0100

Edward Lewis wrote:
> DLV is being touted as a "temporary, non-scaleable hack" to jump start
> DNSSEC adoption.  As such, long range considerations are not mainstream.

That makes it not a candidate for trust anchor rollover, then, surely,
since that is a long range consideration.

> 
> Although ... on http://www.nanog.org/mtg-0606/damas.html it does mention
> DLV as a trust anchor management (avoidance) tool.
> 
> I'm postulate that DLV is trying to be the 6Bone of IPv6.  Perhaps the
> last DLV will expire on 6/6/6 (as in 3006). ;)
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jun 2006 05:12:49 +0000

> Well, I guess I'm a taker if there's any interest in my approach.

me too, for the simplified version of johani's work that i proposed.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 28 Jun 2006 07:44:18 +0200

Thanks Paul and Ben,

But, I am looking for takers for review. It really does not help if  
we have several parties taking their own proposals. We need to  
converge relatively fast now.

I would really appreciate if the working group did the work on  
technical review. If that is not going to happen then the chairs may  
have to pick one of the proposals and have that last called as  
working group output. I don't think that is appropriate.

Paul, your proposal only made it to the mail list and never into a  
draft, correct?

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 28 Jun 2006 07:52:33 +0200

>> start

When I used "nobody put it on the table" I ment to say that nobody  
put it up for considerations. Ben and Ed just reworded my technical  
motivation for saying that I think it should not be considered.

Point is that we have reasonable proposals with reasonable editors  
that all support their own work.  I was genuinely thinking that DLV  
is using a different problem (that of finding all available trust- 
anchors) and hoped that was not one variable that needed to be added  
to the equation.

We need takers for review.

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jun 2006 15:15:25 +0000

> Paul, your proposal only made it to the mail list and never into a draft,
> correct?

it was presented, so there are slides and notes.  i was not planning to write
it up as a draft unless someone somewhere spoke for it.  note: i'm not saying
i want consensus before i write the draft, i just want someone, somewhere, to
say it's an attractive approach that they'd like to see "in the running."  at
the moment, not even johani has said so, and he's the original author.

---

From: Sam Weiler <[email-masked]>
Date: Wed, 28 Jun 2006 11:55:08 -0400 (EDT)

> Because I thought nobody put [DLV] on the table for solving
> trust-anchor rollover (I may be wrong).

Well...  I think draft-weiler-dnssec-dlv-01.txt and 
draft-laurie-dnssec-key-distribution-02.txt are solving nearly the 
same problem.  To the extent that one argues that one of the two is in 
(or out of) scope, I'd expect the same argument to be made about the 
other.

> Wouldn't you agree that also with DLV you need to have a mechanism 
> to roll te DLV anchor?

Arguably, yes.  DLV does, however, solve the problem of rolling over 
other zones' keys.  And once we've gotten to the point where we need 
to roll only one or a few trust anchors, the working group might 
reasonably decide the gain isn't worth the pain.

In other words, while we might use similar technolgy for rollover of 
hundreds of trust anchors at each resolver as we do for rolling just 
one trust anchor, the motivation for developing that rollover 
technology might not be as strong if there's only one trust anchor to 
roll.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jun 2006 16:19:02 +0000

> Arguably, yes.  DLV does, however, solve the problem of rolling over other
> zones' keys.  And once we've gotten to the point where we need to roll only
> one or a few trust anchors, the working group might reasonably decide the
> gain isn't worth the pain.
> 
> hundreds of trust anchors at each resolver as we do for rolling just one
> trust anchor, the motivation for developing that rollover technology might
> not be as strong if there's only one trust anchor to roll.

i believe that the ability to roll trust anchors (which are stored outside
of DNS) is a separate problem from rolling zone keys (which are stored inside
the DNS and which are only sometimes, by policy or because it's the root zone,
also trust anchors.)

in other words, i do not see DLV as a potential resolution of the trust anchor
issue.  if we were willing to cut&paste the root zone's key (and by local
policy, some other set of trust anchors) into every validator, then there
would be no automated trust anchor project going on in this working group.

---

From: Sam Weiler <[email-masked]>
Date: Wed, 28 Jun 2006 11:58:15 -0400 (EDT)

And Ben Laurie writes:

> That makes it not a candidate for trust anchor rollover, then, 
> surely, since that is a long range consideration.

I caution against taking marketing claims about scaling as gospel, 
whether they're claims that something will scale or that it won't. 
Perhaps some data would be helpful.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Jun 2006 13:43:27 -0400

At 11:58 -0400 6/28/06, Sam Weiler wrote:

>I caution against taking marketing claims about scaling as gospel, whether
>they're claims that something will scale or that it won't. Perhaps some data
>would be helpful.

"Being touted as" ... means I am quoting non-specific statements made 
over time about DLV.  But here are two mentions of DLV and scaling, 
followed by my assessment.

Citation 1: http://www.merit.net/mail.archives/nanog/msg00608.html

#can you say "does not scale?"  or how about "works poorly when a
#zone is transferred?"
#
#i think there is no question that you and isc mean well.  but we've
#entered the the twisty passages of security.
#
#randy

Citation 2: http://www.dnssec-deployment.org/dnssec20040630.txt

#DLV - Paul Vixie
#
...
#
#2. DLV is deliberately simple and, in fact, "crippled" in that it is not
#  intended to be scalable or to survive for a long period of time."

Is that the data you want?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jun 2006 18:03:08 +0000

> Is that the data you want?

the dlv draft by sweiler may not be the same thing we implemented in BIND9
and wrote up in <http://www.isc.org/pubs/tn/isc-tn-2006-1.txt>.  sweiler may
be claiming that the dlv in the draft he authored would scale perfectly well.

i will not counter-argue, except to say, isc-tn-2006-1 describes a dlv that
is deliberately crippled, and that this deliberateness came about partly from
our desire not to create a permanent protocol+mechanism through nonconsensus
methods (that of writing it up as an ISC technote rather than an IETF i-d,
and of implementing it in BIND9 as a local-policy exception rather than as
part of an internet standard.)

if sweiler has a dlv that's not deliberately crippled, and if the WG wants to
consider a permanent mechanism (not just an early deployment aid) that is
therefore not-deliberately-crippled, then that's a topic worthy of coverage
here.

but it has nothing to do with my contention that dlv is about zone key
distribution outside of the DS chain, and is therefore a different topic
from automated trust key rollover.  no amount of dlv, in or out of the
standards process, crippled or not, obviates the present need of validator
operators to cut and paste trust anchors like root keys (or dlv keys).

the reason i'm so keen to point out this difference is that when i "riffed"
on johani's key rollover proposal, i considered it unrelated to the need for
(and the use of) dlv.  if we have automated trust key rollover, we will most
likely use it to roll the DLV trust anchor while we wait for the root zone
to have a key we can roll instead.

---

From: Sam Weiler <[email-masked]>
Date: Wed, 28 Jun 2006 16:43:32 -0400 (EDT)

On Wed, 28 Jun 2006, Edward Lewis wrote:

> "Being touted as" ... means I am quoting non-specific statements 
> made over time about DLV.  But here are two mentions of DLV and 
> scaling, followed by my assessment.
...
> Is that the data you want?

Not at all.  I'm looking for data (numbers, examples, case studies) 
supporting the claim that DLV doesn't scale.  I've heard Paul's 
marketing-speak, and I'm skeptical of it.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jun 2006 21:06:54 +0000

> marketing-speak, and I'm skeptical of it.

since i don't know how to prove a negative, i can only say that dlv as
currently implemented in bind9 (which may or may not be compatible with
dlv as described in sweiler's internet draft) is not intended to scale.
the specific place where i expect it to blow chunks is in the number of
unsuppressable queries in a dense dlv namespace.  no simulations have
been done, and the modelling in sweiler's original thesis(*) on dlv makes
slightly different assumptions than those implemented today in bind9.

(*)   S. Weiler, "Deploying DNSSEC Without a Signed Root", Technical
      report 1999-19, Information Networking Institute, Carnegie Mellon
      University, April 2004.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 28 Jun 2006 18:12:51 -0400

> I recall there is a second comparison but I cannot find it.

The table at http://www.dnssec-tools.org/docs/trust-anchor-comparison- 
v02.htm may also be useful.

Suresh
(on behalf of myself)

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 28 Jun 2006 18:33:18 -0500

At 04:19 PM 6/28/2006 +0000, Paul Vixie wrote:
>if we were willing to cut&paste the root zone's key (and by local

Statements: I don't want to start a flame war. I am committed to 
review the keyrollover proposals and participate with my two cents.

I gave a DNSSEC workshop to a carrier in Mexico months ago. When I 
mentioned the keyrollover work being done in the IETF they asked me 
if automatic trust anchor keyrollover is really necessary to deploy 
DNSSECbis and this question has been in my head since.

Since the first time I read about DNSSECbis it became clear the 
usefulness of having a signed root. I know about the trouble of 
signing the root, but when the root is finally signed I expect that 
RSA is broken first before the root zone key is compromised. I expect 
that the entity chosen for root signing implements the same 
operational security that Verising uses to guard its root CA private 
key. If the root is signed and a root key compromise happens, it's 
going to be "big news" (think of CNN alert news) and people will update.

If the root is never signed, IANA can have a list of the trusted 
anchor currently used by each TLD and we know that communication 
between IANA and the TLDs is already authenticated. You can think of 
a lot of operational procedures to propagate this information from 
IANA to end users: windows update, RHN, cvsup, https GET by the DNS 
implementation, etc. The trick is that if you don't update your TA in 
your validator then your client's DNS request will fail and someone 
is going to scream and you will have to fix it. I expect that TLDs 
will implement a security infrastructure (here at NIC Mexico cctld 
.mx we are thinking about FIPS 140-2 level 3 HSMs for example) to 
protect the key so I think that a key rollover should be an isolated event.

Is DNSSECbis deployable without an automatic trust anchor keyrollover 
feature? Maybe what we need is a key management security guideline in 
the spirit of RFC3647 or we can add more operational security best 
practices to the existent dnssec operational practices? Maybe we are 
trying to make a perfect protocol and we just need a pretty good protocol?

Thank you for your comments.

Gustavo Lozano
NIC Mexico

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Jun 2006 01:23:59 +0000

> ... they asked me if automatic trust anchor keyrollover is really necessary
> to deploy DNSSECbis and this question has been in my head since.
> 
> Since the first time I read about DNSSECbis it became clear the usefulness
> of having a signed root. I know about the trouble of signing the root, but
> when the root is finally signed I expect that RSA is broken first before
> the root zone key is compromised.

i agree.  and yet there are two pressures here.  if RSA is somehow broken as
quickly as MD5 was broken (in terms of total years of service per key-size),
then we'll be rolling over to a new crypto alg before the validator population
is large enough that an alg-roll is painful.  on the other hand if RSA lasts
another ten or fifteen years, the validator population could be very large and
many parts of that population will have lost touch with human hands.  in the
former (and expected) case, validator software will have to be upgraded.  in
the latter (very possible) case, automation for trust anchor rollover will be
the only way that Secure DNS could survive.

> ... If the root is signed and a root key compromise happens, it's going to
> be "big news" (think of CNN alert news) and people will update.

i disagree.  people will not update.  people do not update their Windows and
Macintosh systems, even when the wall street journal and every metropolitan
newspaper in the world (plus CNN Nightly News) warns them of the acute need
to do so.  this problem -- not updating -- is at the heart of why ISP's have
no rational course of action when notified of a "botnet" in their customer
network.  this problem is pervasive, and won't be solved by TCPA or any other
initiative announced so far.  Secure DNS should not depend on a solution to
the well known "not updating" problem.

it's possible that one could take the view that validator operators are more
technically "savvy" than Windows/Mac users, and will behave more responsibly
or with some degree of "rational self interest".  this has never been proved
or even shown to be likely.  i note that root name server addresses which
were decommissioned as much as ten years ago still receive hundreds or even
thousands of queries per second.  updates which involve human action toward
static configuration are as unreliable as updates which involve human action
toward software revision levels.  in other words, not reliable at all.

> If the root is never signed, IANA can have a list of the trusted anchor
> currently used by each TLD and we know that communication between IANA and
> the TLDs is already authenticated.

no, it is not.  there's been a string of high-profile TLD hijackings by local
governments or competing commercial entities over the years.  IANA's records
have not always been complete and/or authoritative.

> You can think of a lot of operational procedures to propagate this
> information from IANA to end users: windows update, RHN, cvsup, https GET by
> the DNS implementation, etc. The trick is that if you don't update your TA
> in your validator then your client's DNS request will fail and someone is
> going to scream and you will have to fix it.

possibly.  but it is equally possible that the lack of automation in key
rollover will signal to application developers that Secure DNS is too fragile
to be depended upon.  and also equally possible that some or many failures due
to non-rollover will be undiagnosed or misdiagnosed, causing users and
developers to abandon Secure DNS at the first sign of serious instability.

> feature? Maybe what we need is a key management security guideline in the
> spirit of RFC3647 or we can add more operational security best practices to
> the existent dnssec operational practices? Maybe we are trying to make a
> perfect protocol and we just need a pretty good protocol?

with an expected population of Secure DNS validators on the order of millions,
i assert that the first forced root-key rollover without automation would mean
the end of Secure DNS as it then exists.  others here have further argued that
the "rollover machinery" must be in constant use to ensure its availability
and functionality, and that therefore, root key lifetimes should be only a few
weeks or at most months in length.  (i find those arguments credible, fwiw.)

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 28 Jun 2006 22:02:44 -0400

Gustavo Lozano wrote:

> feature?

For the record, here are the rationales for rolling keys in the first place:

o cryptographic strength concerns, i.e. an old key might be cracked,

o security operations concerns, i.e. over time, the uninterrupted 
confidentiality a production private key becomes less trustworthy,

o survivability concerns to the extent that a scheduled renewal 
operation is like a rehearsal for an emergency private key recovery, or 
an alternative for it (e.g. if the private key breach has no practical 
impact or it is merely suspected).

(from draft-moreau-dnsext-tak-req-00)

Actually this does not answer your question, someone has to weight the 
seriousness of these concerns against the effectiveness and burden/cost 
of TAK rollover solution at hand. I whished the question would have been 
addressed seriously by now in DNSEXT.

-- 

- 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]

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 29 Jun 2006 12:20:33 +0200

> dlv as described in sweiler's internet draft) is not intended to scale.

Well, and the dlv-anchor needs rolling over, for the reasons that
Thierry states (keys get old).

So I think there need two problems to be solved, the roll over of keys
for resolvers that are active on the network. And priming of resolvers
that have been inactive for a (long) time.

I think the rollover drafts are already Good Enough(tm), and I would
like to propose a simple priming idea below.

If the -threshold draft were to include some ideas from the other
drafts, it can become a super-set of the current drafts:
- - revocation of keys (by revoked bit and self-signing) (from the -timers
draft).
- - H(keyset), included automatically or available, reduces polling
bandwidth dramatically. (from paul's idea).
- - Parameter information trouble: fix M (I vote at 3), (from paul's idea).

Also a simple priming key idea. Priming is configured by a URL.
- - The keys are the same SEP keys as those used in key-rollover.
- - If your key-rollover fails, then you can get from the URL a reply of
history: the versions of the DNSKEY and RRSIG(DNSKEY) rrsets that could
have been seen by resolvers. The resolver applies the key-rollover
algorithm to this trace and obtains the latest SEP keys.
- - protocol to the history service is that the client provides the
H(keys) that is the latest he trusts, and the server replies the keyset
the followed the keyset of H(keys) so that the resolver can make one
rollover. The client can then request with the H(keys) of his result the
next keyset, and so on.
- - The trust-anchor zone can provide history service for as far back as
it wants.
- - This makes the priming keys algo as secure as the rollover algo for
key compromise and so on.
- - This could even be in-band as a new query-opcode to a nameserver.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jun 2006 11:19:29 -0400

At 18:33 -0500 6/28/06, Gustavo Lozano wrote:

>Is DNSSECbis deployable without an automatic trust anchor keyrollover feature?

The short answer is "yes, but".

Looking backwards in time, IETF protocols generally have been 
deployed without much consideration for long-term management and 
care.  The result has become that you need to import a particular 
operational environment when attempting to deploy a protocol 
off-the-shelf.

Take a look at the SiteFinder ( 
http://en.wikipedia.org/wiki/Sitefinder [1]) incident to see what 
might happen when a protocol feature is exercised.  Although the 
feature was well within the bounds of the protocol, and even well 
established, the operational environment was upended and a lot of 
problems ensued.

To what extent DNSSEC will be (cost) effective depends on whether or 
not there is an automated means to rollover trust anchors.  Without 
it, DNSSEC will "jump the shark" ( 
http://en.wikipedia.org/wiki/Jump_the_shark [2]) at the first key 
change - if not before.

(Which brings up the question, has DNSSEC already "jumped the shark?")

But, if we wait for there to be a trust anchor feature, we may never 
get further than we already have.

[1] Man, there's a wikipedia page for everything!  It's better than googling...
[2] A page for that too...I'm impressed

---

From: Wesley Griffin <[email-masked]>
Date: Thu, 29 Jun 2006 14:44:39 -0400

> the moment, not even johani has said so, and he's the original author.

I would like to see your proposal as an ID so that it can be properly  
considered along with the rest of the proposals.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Jun 2006 15:41:16 -0400

On Wed, Jun 28, 2006 at 07:44:18AM +0200, Olaf M. Kolkman wrote:

> technical review. 

Colleagues,

In response to the request above, I either reviewed or started to
review four documents, in order to compare them to
draft-ietf-dnsext-rollover-requirements-02.txt, and determine which
(if any) meet the requirements set out in that document (I call it
"the requirements" below).

The documents in question are these:

draft-ietf-dnsext-trustupdate-threshold-01.txt
draft-ietf-dnsext-trustupdate-timers-02.txt
draft-laurie-dnssec-key-distribution-02.txt
draft-moreau-dnsext-takrem-dns-02.txt

I did not review draft-weiler-dnssec-dlv-01.txt yet, because I did
not initially think that it was a candidate to satisfy the
requirements.  I'm happy to do so, however (is that wanted?).  I
thought to send these comments now anyway, in the (perhaps misguided)
hope that they'll be helpful to others in the context of the
discussion.

I quickly concluded that draft-moreau-dnsext-takrem-dns-02.txt could
not meet requirement 5.2, because it is published with a "no
derivative works" rider, and because there are restrictions on the
type of license under which software based on it could be released. 
I therefore did not read the document, and cannot comment on its
quality.  (I did read the table of contents, and the document looks
like it would be interesting to read.)

I read draft-laurie-dnssec-key-distribution-02.txt.  I think it is a
good draft, and that it is an excellent idea for how to handle the
problem of which keys may be trusted when getting SEPs set up.  It
does not, however, appear to be a general solution for trust anchor
management: it seems to violate requirements 5.3 and 5.11.  Unlike
another reviewer, I do not think there are scaling problems with it. 
I believe it provides a useful mechanism for getting DNSSEC "off the
ground" in the absence of the signing of the root, so I think it
should be pursued, but not as a solution to the problems laid out in
the requirements.

Of the remaining two drafts (to which I'll refer as -threshold and
-timers), I believe either one has the potential to meet the
requirements.  In my opinion, there are some advantages to each.  If
I have to pick just one, I slightly prefer -threshold, just because
no bit assignment is required and because its approach to the problem
feels natural to me.  But I don't put any great stock in that
preference: I could support either of these drafts.

Both of the drafts appear more or less to meet all the requirements. 
In what follows, I discuss ways in which I think one or the other is
slightly weaker in meeting the requirements as they are written.  In
the case of requirements I don't mention at all, both drafts meet the
requirement equally and adequately in my opinion.

The first caveat is that there is an IPR claim against both of drafts. 
The registered claim appears to meet requirement 5.2; but it is not
plain to me, since I was unable to find actual terms of use.

My view is that -timers is slightly less scalable (requirement 5.1)
than is -threshold, because of the way -timers queries, but I think
the additional load is almost certainly too little to be worthy of
consideration.

I have a tiny worry about manual operation (5.6) and -timers.  It
appears to me that the wrong kind of manual operation will result in
the Missing state.  I think this could be addressed in the draft,
however.

I think that all-key compromise could be slightly worse for -threshold
than it is for -timers, in that under a total key compromise,
-threshold devolves to STALE, whereas I've managed to convince myself
that the same case in -timers just puts the zone back into an
unsecured state (I may yet un-convince myself of that.  Clue sticks
are welcome).  This is somewhat related to Thierry Moreau's comment
in
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00870.html>;
but my view is ultimately that no protocol is going to save operators
from key mismanagement.  I think both drafts work well in the
presence of good key management regimes.  I do have a worry about
-timers in the case of single key compromise, in that the hold-down
period is at minimum 30 days.  One advantage I see for -threshold in
this case is that the rollover acceptance policy is determined by the
client.  So each of these meets the "unplanned" requirement of
section 5.7 (they both handle planned rolls just fine, as near as I
can tell), but with different potential issues.

A similar set of considerations apply to requirement 5.8.  (I'm
particularly concerned about timeliness in the context of unplanned
events, so that's how I read 5.8.)

I think that -threshold might fail requirement 5.9 in the event of
multiple key compromise or expiry.  This may be a matter of correct
maintenance, though.

While neither document requires a new RR type (5.10), -timers does
need a bit assignment.

Requirements 5.11 itself is slightly confusing to me, because I don't
think there's really any such thing as "replac[ing] an existing Trust
Anchor with another."  It's more exactly a matter of adding one, and
removing another.  Assuming that's what the requirement authors mean
(and I believe it is), I think both drafts meet this.

Because -threshold relies on multiple keys to make up the threshold,
it is entirely possible that in normal operation it would violate
requirement 5.12 (specifically, the "at least one" formulation
therein).  This is true by design, and I think that -threshold's
approach is in keeping with the sentiment behind 5.12 (recovery
should be possible in case of some compromises, but maybe not total
compromise); but -threshold nevertheless cannot meet this requirement
as written.

I believe it is possible to get either -timers or -threshold to
violate requirement 5.13, if you change enough keys fast enough, but
I suspect that would be true of any implementable specification.

Any comments I have on the documents themselves I'll send under
separate heading.

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 30 Jun 2006 22:41:28 -0400

Andrew Sullivan wrote:

> [...]
> 
> This is somewhat related to Thierry Moreau's comment
> in
> from key mismanagement.

Indeed. Furthermore, not all automated TAK rollover are created equal 
with respect to key mismanagement, i.e. some may be more error-prone 
than others. But that is not an evaluation criteria provided by 
draft-ietf-dnsext-rollover-requirements-02.

Regards,

-- 

- Thierry Moreau

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