Subject: state of vixie-dnssec-ter?

From: Samuel Weiler <[email-masked]>
Date: Fri, 16 Sep 2005 18:10:21 -0400 (EDT)

Using the draft dependency graphs at tools.ietf.org, I noticed that
NSEC3 has two references to expired docs:

	an informative reference to dnsext-trustupdate-threshhold

and

	an in-line (only) reference to vixie-dnssec-ter.

Presumably the first will be updated at some point.  Is
vixie-dnssec-ter dead?  I think it only existed as namedroppers posts,
in any case...

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00813.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html

--
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, 17 Sep 2005 16:48:07 +0000

# Is vixie-dnssec-ter dead?  I think it only existed as namedroppers posts, in
# any case...
# 
# http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00813.html
# http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html

if anybody, even one person, tells me that it's useful, i'll dress it up
and send it in.  so far noone, not even one person, has said it was useful
other than as a discussion point for discussions which have now moved on.

---

From: Roy Arends <[email-masked]>
Date: Sat, 17 Sep 2005 19:27:38 +0200 (CEST)

It's useful.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Sat, 17 Sep 2005 17:42:01 +0000

# It's useful.

for what, prospectively?  right now it appears that NSEC3 has its own
coexistence mechanisms, that white-lies updates the -BIS docset, and
there is nothing else on the horizon that could deserve to be called -TER.

shouldn't we wait to define a transition mechanism until we know where
we're going?

---

From: Ben Laurie <[email-masked]>
Date: Sun, 18 Sep 2005 12:36:06 +0100

> there is nothing else on the horizon that could deserve to be called -TER.

There are those that claim that NSEC3's introduction needs to be 
signalled, and hence that -ter is required. This is why we reference it 
in the NSEC3 I-D.

Cheers,

Ben.

-- 
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: Sun, 18 Sep 2005 17:08:21 +0000

# There are those that claim that NSEC3's introduction needs to be signalled,
# and hence that -ter is required. This is why we reference it in the NSEC3
# I-D.

well, ok then.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 19 Sep 2005 15:29:20 +0200

> shouldn't we wait to define a transition mechanism until we know where

Although this list has been silence on the engineering of automatic  
key rollover (except for Jim's mail [1]) we did discuss the issue in  
Paris.  Mike's design does need some of "backwards incompatible"  
addition, hence a transition mechanism (if I'm not mistaken).

I wonder why "algorithm roll" is not sufficient as a transition  
mechanism, did we ever conclude it has deficiencies compared to type  
roll?  Also see draft-ietf-dnsext-dnssec-experiments-01 that covers  
that mechanism and is supposed to be last called soon (at least that  
is what we promised during the last meeting).

- --Olaf

[1]: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ 
msg01231.html

- -----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
We have employment opportunities, see the website.

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 19 Sep 2005 11:28:04 -0400

Olaf M. Kolkman wrote:
> 
> Although this list has been silence on the engineering of automatic  key 
> rollover (except for Jim's mail [1]) we did discuss the issue in  
> Paris.

These two messages are also part of the engineering discussion on KSK 
rollover:

From: Mike StJohns <[email-masked]>
Subject: Issues with draft-ietf-dnsext-trustupdate-threshold-00.txt
at: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01128.html

and

From: Thierry Moreau <[email-masked]>
Subject: Re: DNSEXT Minutes @ IETF-63
at: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01204.html

>   Mike's design does need some of "backwards incompatible"  

I think this is an overstatement (unless the fact that a zone has more 
than one KSK creates a backwards incompatibility). In any event, against 
which key rollover scheme would a scheme be backwards incompatible? The 
only KSK rollover scheme as of now is no rollover, long-lasting KSK, 
isn't it?

However, I have reservations about the effective security of the two 
schemes which use a number of KSK with the assumption that a single KSK 
compromise is sufficiently more likely than a simultaneous compromise of 
every KSK (for to justify either scheme deployment).

As you may know, the document 
http://www.connotech.com/takrem_for_dnssec_01.pdf contains a 
comprehensive discussion.

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]

---

From: Rob Austein <[email-masked]>
Date: Mon, 19 Sep 2005 15:28:35 -0400

At Mon, 19 Sep 2005 15:29:20 +0200, Olaf M Kolkman wrote:
> roll?

We concluded that type code roll was sufficient; we deferred decision
on whether type code roll was necessary.

Keep in mind the context at the time we were looking at transition
mechanisms: we were trying to figure out whether transition was
-possible- so that we'd know whether we could ship DNSSECbis or needed
to go back to the drawing board (yet again) for (another) few years
while we looked zone walking.  In that context, all we needed was one
transition mechanism that was demonstrably sufficient.  Evaluation of
whether any particular transition mechanism necessary depends upon the
specifics of the world to which we wish to transition.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 20 Sep 2005 11:22:34 +0200

> I think this is an overstatement (unless the fact that a zone has  
> more than one KSK creates a backwards incompatibility). In any  
> event, against which key rollover scheme would a scheme be  
> backwards incompatible? The only KSK rollover scheme as of now is  
> no rollover, long-lasting KSK, isn't it?

The problem is that when flipping the revoke bit the key-tag  
changes.  It could be, although the public key material stays the  
same,  that implementations fail to find the key for validation.   
AFAIK the specs only mention that keytag collisions can occur. In  
that sense flipping bits is backwards incompatible, I think :-)

>
> However, I have reservations about the effective security of the  
> two schemes which use a number of KSK with the assumption that a  
> single KSK compromise is sufficiently more likely than a  
> simultaneous compromise of every KSK (for to justify either scheme  
> deployment).
>
> As you may know, the document http://www.connotech.com/ 
> takrem_for_dnssec_01.pdf contains a comprehensive discussion.

In an earlier mail you asked for feedback;  Folk may be hesitant to  
invest any time in this document as long as it does not meet the  
requirement of rfc3978. If you submit this as an internet-draft with  
proper boiler plate you may get more feedback. (Milage may vary, I  
don't expect miracles...)

I reckon that takrem for dnssec  would be covered by the same or  
similar IPR disclosure as takrem for x.509. https:// 
datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=626

As for this proposal becoming part of the solution space for  
automatic key rollover done in DNSEXT, thats up to the folk on this  
list.

- --Olaf

---

From: Mike StJohns <[email-masked]>
Date: Tue, 20 Sep 2005 15:30:03 -0400

At 05:22 AM 9/20/2005, Olaf M. Kolkman wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>>

 From the BIND9 ARM:

The trusted-keys statement can contain multiple key entries, each 
consisting of the key's domain name,
flags, protocol, algorithm, and the base-64 representation of the key data.

Let's do the analysis here.  If I set the revoke bit for a key, and publish 
it, that key will no longer be trusted by the resolver both in current 
implementations and in an implementation that understands the revoke 
bit.  Isn't that the desired behavior?

If the key is not a trust anchor and I set the revoke bit, (and re-sign the 
key RR set) then the chain through from a superior trust anchor will work, 
but since I'm not actually using the key to sign anything else (or at least 
I shouldn't be if I'm the zone owner) there's also no problem.

The only "problem" is that you do stand the possibility of revoking all the 
valid trust anchors and would then have to re-configure the 
resolvers.  OTOH until the resolvers actually understand the revoke bit you 
can unset it and go back to where you were before.

Let's drop this objection to the revoke bit - it's a red herring.

Mike

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 Sep 2005 16:02:34 -0400

> that sense flipping bits is backwards incompatible, I think :-)

Changing the key tag when the revocation bit flips is a -feature- of
Mike's design.

I don't see any obvious need for a transition mechanism, since the
behavior of a revoke-bit-ignorant validator seems be what we'd want
here anyway (well, absent bugs that would cause said validator to
choke on key bits that it doesn't understand).

What am I missing?

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 20 Sep 2005 19:54:51 -0400 (EDT)

> choke on key bits that it doesn't understand).

The obvious questions, from my perspective:

  1) What happens when an old (DNSSECbis, 4033-5) validator runs
     into a zone using one of these funky transition mechanisms?

  2) What happens when a new (funky transition mechanism aware)
     validator runs into an old (manual roll) zone?

For the threshhold scheme, I think #2 above could be very colorful if
the new validators all assume that every zone is using threshhold
stuff -- they could leave old zones unintentionally Bogus.

It may be that Mike's proposal doesn't need a signaling mechanism, but
I'm not convinced anyone has looked that closely at it.

What scared me in Paris was hearing the suggestion that it would be
safe to ignore the questions above and assume everyone will be using
new code -- assume a flag day.  It could be that I heard something
that wasn't being said, but that doesn't remove the need to answer the
two questions above.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 21 Sep 2005 11:36:48 +0200

On Sep 20, 2005, at 21:30 , Mike StJohns wrote:

>
> Let's do the analysis here.  If I set the revoke bit for a key, and  
> publish it, that key will no longer be trusted by the resolver both  
> in current implementations and in an implementation that  
> understands the revoke bit.  Isn't that the desired behavior?
>

Off course the assumption is that the folk that do not follow this  
mechanism had sufficient heads up to configure the new trust-key; but  
that is a fact of current day operations. It took some repetition but  
finally it registered.

> Let's drop this objection to the revoke bit - it's a red herring.

Withdrawn your honor. :-)

> I'm not convinced anyone has looked that closely at it.

The magic words are: implementation and testing. AFAIK Mike's  
proposal only consists of spec-ware (correct?).

- --Olaf

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Sep 2005 13:22:09 +0100

Olaf M. Kolkman wrote:
>>> schemes which use a number of KSK with the assumption that a  single 
>>> KSK compromise is sufficiently more likely than a  simultaneous 
>>> compromise of every KSK (for to justify either scheme  deployment).
>>>
> As for this proposal becoming part of the solution space for  automatic 
> key rollover done in DNSEXT, thats up to the folk on this  list.

FWIW, I took some time to review the document. Essentially the proposal 
is to publish at some point a list of digests of future keys. Key 
rollover is then just a matter of producing the key corresponding to the 
next digest (or, indeed, any digest in the list).

This means, of course, that one needs an offline method of initially 
verifying the digests. This is no worse than the requirement to offline 
verify the initial keys.

There do appear to me to be two flaws with this proposal, one correctable.

a) It uses MASH for the digests. It should probably use SHA-1 (or -256 
et al).

b) It requires all keys to be pregenerated, so a compromise of the 
pregenerated keys cannot be recovered from.

Also, the document includes no IP statement that I could find.

Cheers,

Ben.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 21 Sep 2005 11:48:13 -0400

> next digest (or, indeed, any digest in the list).

Thanks for the feedback on 
http://www.connotech.com/takrem_for_dnssec_01.pdf.

> verifying the digests. This is no worse than the requirement to offline 

I don't exactly understand who is the *one* who needs verification, and 
what is *offline* in this context? Perhaps you refer to a veryfing party 
(a DNS resolver system) needing initial *trust* by an *out-of-band* 
mechanism upon initial trust anchor configuration. This is part of the 
picture for any scheme.

Indeed, a resolver initially accepts the digests as trusted as 
originating from the DNS zone manager. Any trust anchor key renewal 
proposal is based on an initial trust decision.

> a) It uses MASH for the digests. It should probably use SHA-1 (or -256 

The key idea is cryptographic strength over the long run (which is a 
justification for key rollover in the first place). MASH with hidden 
parameters (until the key rollover message is received) is assumed to be 
more resistant than a fixed Hash function.

This can lead to the follwing sub-issues:

a) Is such attention paid to cryptographic strength required by typical 
DNSSEC participants? Perhaps no.

b) Is such attention paid to cryptographic strength required by some 
DNSSEC extension influencors? Perhaps yes.

c) What the cryptographers would think of MASH with hidden parameters as 
a *strong* mechanism in the long run? ...

> pregenerated keys cannot be recovered from.

Any proposal for trust anchor rollover has a catastrophic failure mode 
(i.e. when the security incident recovery is exactly like the initial 
trust anchor configuration). You correctly point to the one specific to 
the TAKREM proposal.

In practice, to reduce the likelihood of a catastrophic failure, each of 
the pregenerated keys can be stored in a couple of pages of bar code 
labels put in a tamper-evident sealed envelope, in dual-components (i.e. 
two sets of envelopes, each set stored in a different safe box).

> Also, the document includes no IP statement that I could find.

Such IP statement would be in the IETF IPR disclosure database. Since a 
formal draft is not yet submitted, the IPR disclosure is not files. But 
see the observation by Olaf above, TAKREM for X.509 being covered by the 
draft draft-moreau-pkix-takrem-01.txt, which has an IPR disclosure in 
the IETF database.

Regards,

-- 

- Thierry Moreau

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Sep 2005 16:34:39 +0100

Thierry Moreau wrote:
>> FWIW, I took some time to review the document. Essentially the 
>> proposal is to publish at some point a list of digests of future keys. 
>> Key rollover is then just a matter of producing the key corresponding 
>> to the next digest (or, indeed, any digest in the list).
> 
> 
>> verifying the digests. This is no worse than the requirement to 
>> offline verify the initial keys.
> 
> 
> mechanism upon initial trust anchor configuration.

Indeed I am.

> This is part of the picture for any scheme.

This is what I said.

> proposal is based on an initial trust decision.

True.

> more resistant than a fixed Hash function.

On what basis?

> draft draft-moreau-pkix-takrem-01.txt, which has an IPR disclosure in 

Are you going to make us look for it, or just tell us what it says?

Cheers,

Ben.

---

From: Mike StJohns <[email-masked]>
Date: Wed, 21 Sep 2005 16:54:56 -0400

At 05:36 AM 9/21/2005, Olaf M. Kolkman wrote:

>proposal only consists of spec-ware (correct?).

In a private note to Olaf I pointed out that this is neither a requirement 
of becoming an ID nor of becoming an RFC.  Its not an appropriate comment 
from a WG chair to suggest this is a failing of an ID or proposal.

I'd also like to point out that my draft is the only active draft as the 
other one has been expired for a while and has not been re-submitted as 
promised.

Also, my comments on the faults in the timing model of the other proposal 
haven't garnered any counter-comments so I have to assume there are no 
counter arguments.

In any event this has been going on for 18 months with little if any 
movement.  Either we're going to do something about trust anchor rollover 
or we're not.   If there is no conclusion by the end of November, and 
absent any compelling reason not to, I'll be withdrawing my draft.

Later, Mike

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Sep 2005 21:20:12 +0000

# In any event this has been going on for 18 mos with little if any movement.

but what a lovely excuse this has made for further delaying deployment,
even among the people who have been too busy to even read your draft.

# Either we're going to do something about trust anchor rollover or we're not.

i estimate "not".  but i feel sure we won't deploy without it, or if without
this, then not without something else somebody hasn't mentioned yet or lately.

# If there is no conclusion by the end of November, and absent any compelling
# reason not to, I'll be withdrawing my draft.

can the chairs ask some pointed questions?  like:

1. is dnssec-bis deployable without this kind of key management?
2. is dnssec-bis deployable without any other kinds of key management?
3. is dnssec-bis deployable without anything unrelated to key management?

4. does mike's proposal appear to be unworkable?  if so, how or why?
5. does mike's proposal solve the wrong problem?  if so, how or why?
6. does mike's proposal fail to solve the whole problem?  if so, how or why?

7. does a competing proposal offer a more provable/testable/simple solution?
8. does a competing proposal solve at least the same important problems?
9. does a competing proposal solve important problems this one doesn't address?

silence on these questions should equal "i have either read the draft and find
none of these faults, or i promise to shut up about it if i read it later on."

here's something fun from the archives:

	Date: Thu, 5 Dec 1996 09:52:33 -0500 (EST)
	From: "Donald E. Eastlake 3rd" <[email-masked]>
	To: Samuli Mattila <[email-masked]>
	Cc: [email-masked], [email-masked], [email-masked]
	Subject: Re: key revokation in DNSSEC
	Sender: [email-masked]

	The original DNSSEC proposal by myself and Charlie Kaufman had a key
	revocation scheme but the overwhelming consensus of the WG was to
	leave that out for now.

	...

what do we want to be talking about on 5-DEC-2016?  still dnssec deployability?

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Sep 2005 15:54:57 -0700

Hi,

Having not read the draft, I can make no comment on it, however:

On Sep 21, 2005, at 1:54 PM, Mike StJohns wrote:
> In a private note to Olaf I pointed out that this is neither a  
> requirement of becoming an ID nor of becoming an RFC.  Its not an  
> appropriate comment from a WG chair to suggest this is a failing of  
> an ID or proposal.

What Mike says is true.  The IETF moved away from "running code" long  
ago.  To impose a requirement of implementation and testing on a  
particular document and not others is ... questionable.  My personal  
preference would be to require implementation for all drafts, but  
that's neither here nor there...

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Wed, 21 Sep 2005 23:01:41 -0400

At 16:54 -0400 9/21/05, Mike StJohns wrote:

>In any event this has been going on for 18 months with little if any movement.
>Either we're going to do something about trust anchor rollover or we're not.
>If there is no conclusion by the end of November, and absent any compelling
>reason not to, I'll be withdrawing my draft.

IMHO, with the recent developments in "se." and "ripe.net.", perhaps 
interest will rise.

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

If you knew what I was thinking, you'd understand what I was saying.

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 22 Sep 2005 02:34:18 -0400

>>> [...]
>>> a) It uses MASH for the digests. It should probably use SHA-1 (or 
>>> -256 et al).
>>
> Thierry Moreau wrote:
>>
>> parameters (until the key rollover message is received) is assumed to 
>> be more resistant than a fixed Hash function.
> 
> On what basis?

Primo, MASH is "Modular Arithmetic" cryptographic primitive based on the
X^2 mod N primitive (Rabin-Williams cryptosystems family). We can then 
refer to the initial MASH design rationales, the history of 
Rabin-Williams cryptosystems, and recent theoretical results on the 
"provable security".

Secundo, MASH allows the flexible selection of cryptographic strength
(no issue of algorithm rollover, no digest type to select among e.g.
SHA-1 or SHA-..., just pick up larger parameters).

Tertio, MASH has parameters that allow the (hidden) selection of
parameters, i.e. a hash function selection among a family.

Quarto, the bad performance of MASH has negligible impact for trust
anchor key rollover, at a nominal frequency of 0.000000032 transaction
per second (once per year).

Quinto, the alternative, SHA-1 SHA-... carries the potential for
delay-incuding debates due to the recent security weakening of SHA-1
from 2^80 to 2^69.

About primo, I can provide a few academic references if it helps
About secundo and tertio, see http://www.connotech.com/takrem.pdf
About quinto, see e.g. 
http://www.csrc.nist.gov/pki/HashWorkshop/participation.html

Regards,

-- 

- Thierry Moreau

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

---

From: Alex Bligh <[email-masked]>
Date: Thu, 22 Sep 2005 10:14:08 +0100

--On 22 September 2005 02:34 -0400 Thierry Moreau 
<[email-masked]> wrote:

> Primo, MASH is "Modular Arithmetic" cryptographic primitive

Excuse my ignorance on the subject, but is MASH demonstrably unencumbered
by IPR concerns (like SHA-x)?

Given the main attack on *long* hashes these days seems to be legal as
opposed to computational, I wonder whether selecting SHA-(largenum) isn't
better purely because the algorithms, implementations, and IPR
considerations are already widely known.

(No, I don't feel strongly about this, my eyebrows just raise when we
pick another crypto-algorithm-du-jour)

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 22 Sep 2005 16:19:48 +0200

I am afraid I fell in the trap of wearing to many hats; chair,  
"competing" document co-author, interested participant of DNSEXT and  
active deployer of DNSSEC.

> appropriate comment from a WG chair to suggest this is a failing of  

I did not try suggest that this document could not go forward without  
an implementation. I was merely responding to Sam's statement. He was  
questioning if there needed to be a signaling mechanism. My  
experience with DNSSEC protocol development I've been involved in is  
that that is the kind of thing one finds out by actually going  
through the operational motions i.e. by experimenting with an  
implementation. It would be nice to have such implementation was  
essentially what I tried to say, as "namedropper".

But you are correct: There is no IETF-process requirement  on having  
an implementation. And I, as chair, don't want to break the process  
by imposing such requirement. [*]

> In any event this has been going on for 18 months with little if  
> any movement.  Either we're going to do something about trust  
> anchor rollover or we're not.   If there is no conclusion by the  
> end of November, and absent any compelling reason not to, I'll be  
> withdrawing my draft.

There are many reasons for not seeing any progress and I share Mike's  
frustration. I am prepared to take some of the blame, not all. But  
lets not

As a co-author of the 'competing' work I have not done much to push  
that work, as a matter of fact I over the last months I have been  
more and more convinced that there is very little difference between  
the two proposals and that it is not worth to turn those into  
religious items.

As a DNSSEC deployer I agree with Paul's statement that DNSSEC will  
not fly without some rollover mechanism.

As a namedropper I'd happily spend my energy on getting closure on  
Mike's document.

--Olaf

[*] <chair hat> I do think that --- although there is no process  
requirement -- this group agreed that some experiments with NSEC3  
would be useful for forward progress, please tell me if you think I'm  
wrong.</chair hat>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 22 Sep 2005 16:23:01 +0200

> can the chairs ask some pointed questions?  like:

Thanks for the instructions .... ;-)

> 9. does a competing proposal solve important problems this one  

Sounds like you are asking us to do a last call.

- --Olaf (hat on)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 22 Sep 2005 10:40:29 -0400

>Sounds like you are asking us to do a last call.

More like a "first call" to me...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 22 Sep 2005 11:08:21 -0400 (EDT)

> absent any compelling reason not to, I'll be withdrawing my draft.

It's not clear to me what you want the WG to "do" or "conclude".
Could you be more specific?

I see no problem with the WG keeping both drafts active, assuming
there are proponents for each approach.  Your message above as well as
your comments in Paris suggest to me that you don't want to be such a
proponent for this technology -- if that is indeed the case, then I
hope you will withdraw the draft posthaste.

-- Sam

---

From: Matt Larson <[email-masked]>
Date: Thu, 22 Sep 2005 11:27:37 -0400

> would be useful for forward progress, please tell me if you think I'm  

We have heard from multiple parties who want the various features
offered by NSEC3.  Therefore, keeping this document moving and having
a workshop seems like a good idea.  VeriSign will have an
implementation to participate with.

Matt

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Sep 2005 17:19:25 +0000

# > can the chairs ask some pointed questions?  like:
# 
# Thanks for the instructions .... ;-)

not instructions, just a request.

# > 1. is dnssec-bis deployable without this kind of key management?
# > 2. is dnssec-bis deployable without any other kinds of key management?
# > 3. is dnssec-bis deployable without anything unrelated to key  management?
# >
# > 4. does mike's proposal appear to be unworkable?  if so, how or why?
# > 5. does mike's proposal solve the wrong problem?  if so, how or why?
# > 6. does mike's proposal fail to solve the whole problem?  if so,  how or
# > why?
# >
# > 7. does a competing proposal offer a more provable/testable/simple
# > solution?
# > 8. does a competing proposal solve at least the same important  problems?
# > 9. does a competing proposal solve important problems this one  doesn't
# > address?
# >
# 
# Sounds like you are asking us to do a last call.

not at all.  if the WG doesn't know the answers to those questions well before
we get to the point of WGLC, then we're going to be "in the weeds" forever.

---

From: Mike StJohns <[email-masked]>
Date: Thu, 22 Sep 2005 13:21:11 -0400

>Could you be more specific?

Check the record.  18 months ago the WG accepted these two drafts as work 
items with the idea that one approach would become blessed and the WG would 
do an RFC from it.  That decision never happened.  Unlike you I see large 
problems with having two different approaches to doing a trust anchor 
rollover.  So the "conclusion" I'm looking for is which approach to pursue 
and the default is that if the WG doesn't decide by November it will be the 
other draft.  At this point its becoming more important to get something 
published and fielded than to argue about which approach is better.  OTOH 
unless the other draft is resubmitted soon that's going to leave us with no 
approach.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 22 Sep 2005 17:51:10 -0400 (EDT)

Err, I don't think Mike or David are correct. While many have lamented the "lack
of running code" for many RFCs, I think the official policy (RFC2026) for 2 or
more working implementations for "Draft Standard" status has not been changed.  

While there is no requirement for a _draft_ to have working code, obviously
chicken and egg, it is entirely appropriate for the chairs of various working
groups to criticize moving ahead drafts that aren't supported at all by working
code to "Proposed Standard" RFCs.  "Proposed Standard" status requires among
other things, that there be no technical omissions unless waived by the IESG. 

While a working implementation is not absolutely required, as RFC2026 notes in
section 4.1.1, working code is a strong argument in favor. It goes unsaid that
lack of working code is a strong argument against considering a draft mature
enough to become a "Proposed Standard".  Plainly, if no one is going to bother
to implement something, its consideration of RFC maturity is probably a waste of
time.

The recent failures [hence the grumbling about having "moved away"] of some WG
chairs to require working code does not alter the policy of the IETF.

If, however, the IETF policy has in fact been changed without my noticing,
please provide a link to the new controlling RFC updating this policy.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Sep 2005 13:02:16 +0100

> implementation to participate with.

And I have one for BIND 9 (server and dig).

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Sep 2005 13:06:11 +0100

Mike StJohns wrote:
> Check the record.  18 months ago the WG accepted these two drafts as 
> work items with the idea that one approach would become blessed and the 
> WG would do an RFC from it.  That decision never happened.  Unlike you I 
> see large problems with having two different approaches to doing a trust 
> anchor rollover.  So the "conclusion" I'm looking for is which approach 
> to pursue and the default is that if the WG doesn't decide by November 
> it will be the other draft.  At this point its becoming more important 
> to get something published and fielded than to argue about which 
> approach is better.  OTOH unless the other draft is resubmitted soon 
> that's going to leave us with no approach.

There's my "web of trust" approach (which also handles key 
distribution). I've heard renewed interest in this recently.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 23 Sep 2005 13:08:25 -0400

<chair-hat=off>

For the discussion below I will only comment on the proposals that I
have studied, Mike's, N-of-M and DLV.

># > 1. is dnssec-bis deployable without this kind of key management?

Yes, on a small scale.
Someone can configure a validator to trust a small set of zones, and
maintain that, but not on a global scale.

># > 2. is dnssec-bis deployable without any other kinds of key management?

Not on a wide scale.

># > 3. is dnssec-bis deployable without anything unrelated to key  management?

Not sure what exactly you are asking here :-)
But if you are asking is what does DNSSEC need to get deployed the
answer is "Large customer that can not live without it!"

># > 4. does mike's proposal appear to be unworkable?  if so, how or why?

Not at all, it works fine. I have spent quite a bit of time thinking
about it and doing simulations of it (in my head and on paper).
In my mind there are three things in Mike's proposal that are real
elegant and make it an attractive solution.

1. Probation on trust relation ship: A new DNSKEY with SEP bit can
not be inserted into a DNSKEY RRset and be trusted, it needs to
stay around to gain acceptance.

2. Immediate revocation: The beauty of the Revoke bit is as soon as
the bit is set it the DNSKEY it is set on is not trusted anymore.
But at the same time a Mike-aware keymanager[1] can notice that a
DNSKEY it trusted has been revoked and remove it from the trusted list.

3. Omission leads to probation which leads to removal:
If DNSKEY is removed from the DNSKEY RRset it is put on probation, if it
does not appear again during the probation it can be deleted from memory.

># > 5. does mike's proposal solve the wrong problem?  if so, how or why?

No it is solving the right problem.

># > 6. does mike's proposal fail to solve the whole problem?  if so,  how or

It does not solve one part of the Key Management problem: initial trust.

But the same goes for all the other proposals I have seen so far.
DLV is one that attempts to aggregate trust relationships and allow
new trust relationships to be established over time. (In this case
I thought is that some combination of Mike's probation and using
multiple (N-of-M) DLV trees before starting to trust a new entity).

Mike's proposal solves the problem of continuing trusting someone.

There is one sub problem that I have not convinced myself if that needs to
be solved in general> Thus I have not thought the issue through
but want to mention the issue:
Can a *-aware keymanger[1] be configured, then put on the shelf for
x months before being connected to the Internet and learn all changes
to trust anchors and be up to date in a short order?

IMHO this is a question of requirements, we can either solve this in
protocol, or the KM can securely fetch an updated configuration from
the entity that configured the KM, which hopefully was on-line during this
time.

># > 7. does a competing proposal offer a more provable/testable/simple
The tradeoffs are in how rapidly new keys can be introduced/revoked.
The N-of-M proposal allows more rapid changes, mainly in introducing new
DNSKEY's. The N-of-M proposal is little bit simpler to test as it does not
need long testing or simulated time. Mike's proposal can be tested by using
shortened timer values.

># > 8. does a competing proposal solve at least the same important  problems?

yes

># > 9. does a competing proposal solve important problems this one  doesn't

None that I can express.

         Olafur

[1] Terminology nit:  Keymanager: people keep using the words "resolver" or
"validator" when talking about the functional unit that decides which
DNSKEY's to trust. In my mind the resolver is a traditional DNS resolver
that looks for answers, validator is a tool that is given a set of
trusted-keys and it checks if it can validate some DNS signatures to
allow it to assess the status of a particular RRset. The entity that
supplies the trusted-keys is a KeyManager. This can be static as
in Bind9 via the trusted-keys statement, or a functional unit that
maintains a list of keys to trust, using some mechanism, this could
be DLV lookup, Mike-aware DNS lookups, N-of-M-aware lookups,
LDAP into a database (that is somehow maintained), etc.

---

From: Mike StJohns <[email-masked]>
Date: Fri, 23 Sep 2005 13:36:43 -0400

>does not appear again during the probation it can be deleted from memory.

Actually, see the state table in the last two drafts.  The above was the 
case in the first (non-WG) draft, and was reflected in a set of slides I 
did to brief the initial draft, but I removed the delete on time out for 
missing (but unrevoked) keys.  The reason for that was to prevent an 
attacker who gets the private part of one key from causing another key to 
go invalid.   A design decision, but one which made sense with the overall 
goal of being able to recover from an N-1 key compromise where N was the 
number of keys at a trust point.