Subject: Rants on auth denial

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Mar 2005 14:21:36 -0500

I called a friend and ranted for a few minutes on the topic of 
authenticated denial.  Because of time constraints, it was good to 
get it out of my system, albeit in a way only one other could hear.

In this message I'll sketch out the points I made, if I can recall 
them...this is more rant than discussion fodder or a set of 
conclusions.  It' all IMHO.

1) On-line signing is a non-starter for performance reasons.  DDoS - 
there are many ways to filter out suspect packets and dump them on 
the floor.  However, it is hard to profile bad DNS packets, whose 
intent is to incur on-line signing of a negative answer.

Once exposed to packets generated by DDos (whether or not on-line 
signing is done), the only way a server is to survive is to be able 
to dispatch the packets faster than they arrive.  (Think 
Queuing/Markov theory, distribution of inter-arrival times and 
service times, probability of there being 0 waiters in the queue.) 
Routers can work at wire speed plus, and simple lookup has a chance 
too.  But I'm afraid crypto is out of the question.

2) On-line signing is a non-starter for key management issues.  Have 
one key for all servers?  The problem is that one compromised server 
compromises all.  One key per server?  Then my RRSet will be large. 
Want a different key for the off-line signing?  Can't indicate that 
in DNSSEC, we did try that once - maybe we could make it work this 
time, with a protocol change.

3) Making simplifying assumptions about server layout restricts 
operational flexibility.  I should be able to get a slave machine 
from someone without having to give them secrets that could sign my 
zone.  (TSIG is okay, it can't sign the zone.)  I should be able to 
deploy machines based on demand - both queries per second and latency 
- without worrying about having to scale or compromise key management 
practices.

4) I really think that pre-computing the answers, as NSEC does, is a 
bigger asset than we've realized.  It is what allows us to not fear 
DDoS as much.  It also removes the problems of key management.

5) Why is zone walking an issue?  I don't buy privacy as the 
motivation.  I don't mean to argue this in this venue, but I see that 
you can get the gTLD zone files pretty easily.  I don't see a lot of 
outcry over abuses of those zones with this availability.

I don't mean to aver that this is a solid rebuttal to those concerned 
about privacy.  But as a naive (certainly in the way of privacy and 
the law) person, I don't see "it."  Perhaps ICANN (for the gTLDs) is 
a more appropriate venue to argue this.

6) I don't think that zone walking is that great a deal for the 
registries. Unless the registry just doesn't want the list of 
registrants known.  For a registry's DNS, I am not sold that zone 
walk traffic will be significantly noticeable buried with all the 
other DNS nuisance traffic.

7) However I do think there is a zone walking issue in other places. 
For instance:

7a) I want to put my X509 certificates for my employees on-line.  Yet 
I mark the company phone book "proprietary and confidential."

7b) One of the advantages of IPv6 addresses are that they are sparse. 
This makes randomly choosing an target address less useful than in 
IPv4.  If I can zone walk the IPv6 reverse tree (if it exists, it 
might if we want opportunistic encryption, etc.), the sparseness 
advantage disappears.  What about RFID?

As you might see, there are future uses for DNS and DNSSEC that may 
open up the problem space.

8) Choosing one approach that is appropriate for only those who care 
"now" is myopic.  We can't survive with different camps operating a 
common resource like DNS in different ways - fragmentation is bad.

9) We have to remember that any client-server protocol has to keep in 
mind that there are two sets of semantics.  The server-side and 
client-side can be different.  I say this as background to the issue 
of whether H(name) is a problem or not.  I don't think it's that big 
a deal.  However, H(name) has to somehow avoid flatting a zone's 
(sub)tree - and we can't assume that only one-label zones will use an 
alt-NSEC.

10) DNSSEC lacks a really cool feature - the ability to upgrade your 
security without making you less secure.  E.g., I stipulate that my 
zone are only signed with a super safe crypto algorithm.  If super 
safe isn't super available, then the majority of the world downgrades 
me to unsigned (with respect to any popular crypto algorithm). I 
mention this because if a zone elects to use some non-NSEC approach 
in place of NSEC, they appear improperly (or not at all) secure.

My conclusion is that someone (not me, I'm busy now with EPP and 
DNSSEC, etc.) needs to work out a way to make per-label hashing work. 
I think that this is more promising than on-line signing approaches. 
I think that this is also more promising than hashing a whole name. 
After all, it's not the tree structure we want to hide, but the label 
identities.

Can this be done without a protocol change?  Probably not.  I'm not 
calling for a halt to the DNSSECbis documents, etc., but I still 
haven't seen the light on how we can overcome what's in #10.  Even 
with a transition mechanism in place.

It's been a while since I've ranted on this, see this message around 
the last time I thought much on this (near the IETF in San Diego):

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html

My opinion on the option I label 2b2 may be different because of #9 
above - we don't need to create a name space for the hashes.  The 
client just needs to know how to hash what it has (the labels in the 
QNAME) in the same way as the server did to generate the response. 
The server does need to have a list of the hashes for all the 
labels/names in the zone, but they don't need to be tied to the tree. 
So what if H(label).example is the same as label2.example.?  I don't 
see that as a problem.

The approach to pre-computed responses approaches is to convince the 
client that the server executed RFC 1034, 4.3.2 (as amended) 
correctly.  That's what we need to accomplish.  NSEC does this now, 
but allows enumeration.  One-way hashes theoretically can stop this.

There is one item I'd challenge anyone thinking about all this ... 
say something about troubleshooting.  How can an operator verify that 
the responses being given are correct and not the result of a bad 
floating point accelerator or buggy cryptolibrary?

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

Achieving total enlightenment has taught me that ignorance is bliss.

--
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: Ben Laurie <[email-masked]>
Date: Fri, 18 Mar 2005 11:15:04 +0000

Edward Lewis wrote:
> client-side can be different.  I say this as background to the issue of 
> whether H(name) is a problem or not.  I don't think it's that big a 
> deal.  However, H(name) has to somehow avoid flatting a zone's (sub)tree 
> - and we can't assume that only one-label zones will use an alt-NSEC.

You make this statement as if it is somehow obvious that per-label 
hashes are good, and whole-name hashes are bad. You use the term 
"flattening the zone" as if NSEC3 records had anything to do with the 
shape of the zone. The zone is the shape it is, regardless of how you 
deny existence of non-existent names. Enlighten me - what are you on about?

> security without making you less secure.  E.g., I stipulate that my zone 
> are only signed with a super safe crypto algorithm.  If super safe isn't 
> super available, then the majority of the world downgrades me to 
> unsigned (with respect to any popular crypto algorithm). I mention this 
> because if a zone elects to use some non-NSEC approach in place of NSEC, 
> they appear improperly (or not at all) secure.

You mean they appear insecure to a resolver that does not support the 
non-NSEC approach.

> My conclusion is that someone (not me, I'm busy now with EPP and DNSSEC, 
> etc.) needs to work out a way to make per-label hashing work. I think 
> that this is more promising than on-line signing approaches. I think 
> that this is also more promising than hashing a whole name. After all, 
> it's not the tree structure we want to hide, but the label identities.

I do not understand why this is better.

> calling for a halt to the DNSSECbis documents, etc., but I still haven't 
> seen the light on how we can overcome what's in #10.  Even with a 
> transition mechanism in place.
> 
> It's been a while since I've ranted on this, see this message around the 
> last time I thought much on this (near the IETF in San Diego):
> 
> above - we don't need to create a name space for the hashes.  The client 
> just needs to know how to hash what it has (the labels in the QNAME) in 
> the same way as the server did to generate the response. The server does 
> need to have a list of the hashes for all the labels/names in the zone, 
> but they don't need to be tied to the tree. So what if H(label).example 
> is the same as label2.example.?  I don't see that as a problem.
> 
> client that the server executed RFC 1034, 4.3.2 (as amended) correctly.  
> That's what we need to accomplish.  NSEC does this now, but allows 
> enumeration.  One-way hashes theoretically can stop this.
> 
> There is one item I'd challenge anyone thinking about all this ... say 
> something about troubleshooting.  How can an operator verify that the 
> responses being given are correct and not the result of a bad floating 
> point accelerator or buggy cryptolibrary?

If an operator wants to check the responses, all they need do is perform 
the hashes with an independent implementation and verify that it matches 
the hashes in the zones.

I'd note that bad crypto implementations tend to not go undetected for 
long, since they produce nonsense or verification failures.

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: [email-masked] (Geoffrey Sisson)
Date: Fri, 18 Mar 2005 11:27:38 +0000 (GMT)

Edward Lewis <[email-masked]> writes:

> conclusions.

Much of this has been discussed previously; I don't wish to open these
debates again but feel that some response is neccessary.  To summarise
the salient points:

1. Privacy of zone data is an issue for some TLDs.  (These include
   several not-for-profit ccTLDs so greed isn't neccessarily the
   primary motivation.)

2. Even if privacy isn't an issue, the availabilty of NSEC RRs may
   result in substantial `nuisance' traffic as they may be used to
   create frequent snapshots to diff for name availabilty in
   registry-operated zones.  Zone walking may employ parallel
   techniques so the resultant traffic may not be well-behaved.

3. Online signing is viewed (by us at least) as an interim solution to
   expidite the deployment of DNSSEC rather than waiting for `DNSSECter'.
   The performance issue has been noted but it's been suggested that
   suitably accelerated hardware should be able to do this at wire
   speed at gigabit rates (though AFAICT the impact of a move to longer
   keys hasn't been discussed).

Regards

Geoff

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 Mar 2005 19:35:40 +0100

* Edward Lewis:

> registries.

Some registries have expressed their wishes to keep their zone files
to themselves.  Not everyone is under contractual obligation to
publish them, and there seem to be strong business interests not do so
if at all possible (e.g. if you are a legacy ccTLD not yet under ICANN
control).

I don't buy the privacy argument either because such registries
happily expose WHOIS information to the general public, without a way
to opt out and lacking a clear technical need for that data (domain
WHOIS is mostly used by lawyers).

---

From: Edward Lewis <[email-masked]>
Date: Sun, 20 Mar 2005 22:06:17 -0500

Trying to tie all the responses back to one thread...

At 11:15 +0000 3/18/05, Ben Laurie wrote:
>Edward Lewis wrote:
>>  9) We have to remember that any client-server protocol has to keep in mind
>>that there are two sets of semantics.  The server-side ...
>...snip...
>>... H(name) has to somehow avoid flatting a zone's (sub)tree - and we can't
>>assume that only one-label zones will use an alt-NSEC.
>
>You make this statement as if it is somehow obvious that per-label hashes
>are good, and whole-name hashes are bad. You use the term "flattening the
>zone" as if NSEC3 records had anything to do with the shape of the zone.
>The zone is the shape it is, regardless of how you deny existence of
>non-existent names. Enlighten me - what are you on about?

The problem with demonstrating the closest encloser that is handled 
by having to either include extra neg-answer records (to show that 
the encloser identified is indeed closest) or to stuff in records at 
otherwise empty non-terminals.

>>security without making you less secure.  E.g., I stipulate ...
>...snip...
>>... mention this because if a zone elects to use some non-NSEC approach

Yes, but this isn't just a problem for NSEC, it's a general design problem.

>>DNSSEC, etc.) needs to work out a way to make per-label hashing ...
>...snip...
>>... also more promising than hashing a whole name. After all, it's not the
>>tree structure we want to hide, but the label identities.
>

Not having to mess with empty non-terminals, better handling of 
multi-label-depth zones.

>...snip...
>>... verify that the responses being given are correct and not the result
>>of a bad floating point accelerator or buggy cryptolibrary?
>

If operations were so simple. ;)  I just see the existing documents 
as overly concerned with the "science" and not operationally vetted.

>    several not-for-profit ccTLDs so greed isn't neccessarily the

It wouldn't be fair to call motivation into question.  But, usually 
when I say a problem has it's roots in situation "Y", I look into 
other solutions to situation "Y" for inspiration.

My point is that I don't see how other solutions to privacy issues 
can play a role here.

>    techniques so the resultant traffic may not be well-behaved.

"May" is the key word.

>    keys hasn't been discussed).

That may be.  If so, they why is this a working group issue?  An 
implementation is free to generate negative answers in any matter it 
chooses.

An implementation may decide to "register" the name before and after 
the "victim" of an name error condition, construct the NSEC record, 
sign it, return the answer, then unregister the two names.  This 
would make this legal with the NSEC record as defined without 
exposing "real" names.  Anyone choosing to do this would face the 
operational impacts, nad have to deal with the key management and 
performance issues.

None of what I have mentioned is related to interoperability, so I 
think it's not an IETF standards issue.

>if at all possible (e.g. if you are a legacy ccTLD not yet under ICANN

This is true.  I don't mean to say that all registries should adhere 
to ICANN policies.  I'm using such situations as examples that there 
is not technological disaster that needs to be solved.

>WHOIS is mostly used by lawyers).

Ack.

But I wanted to close with this: I suspect that non-registries may 
find they have problems with zone walking.  If this *becomes* a 
reality, then the solution to zone walking had not be optimized for 
(or assume) registry situations.

E.g., in such situations slaves might provided on machines on which 
the zone admin would not be willing to place a secret key authorized 
to sign the zone's answers.  (Major registries assume they "own" all 
of their DNS servers.)

---

From: Alex Bligh <[email-masked]>
Date: Mon, 21 Mar 2005 09:08:51 +0000

--On 20 March 2005 22:06 -0500 Edward Lewis <[email-masked]> wrote:

> But I wanted to close with this: I suspect that non-registries may find
> they have problems with zone walking.  If this *becomes* a reality, then
> the solution to zone walking had not be optimized for (or assume)
> registry situations.

At risk of reopening a can of worms, I think this is a reasonably point.
NSEC was designed with a feature (enumerability) in that proved inimical
to a subset of users of one particular type (registries) rather too
late in the day. For whatever reason (too little registry involvement,
too little w/g outreach, whatever, doesn't matter for this point) those
designing the protocol did not know that a subset of this user type
would not want enumerability. It would be a shame if we made the
same mistake with the fix. It would surely be better to say "let
us assume, that any current use-case for DNS might want to use
the features of NSEC3 [currently also opt-in]". That probably sets
a slightly higher bar in terms of "will this work for operators" but
might at least delay the calls for NSEC4 when a different subset of
users finds it doesn't work for them on deployment.

I think this is the similar to Ed's point 8. It's precisely where NSEC
fell down the first time.

> That may be.  If so, they why is this a working group issue?

The virtue of this group being a personal opinions group is I can (mostly)
agree with Ed here. Online signing seems to me at best a sticking plaster,
and at worst a recipe for disaster. Internet traffic would seem to grow
faster than crypto-processing ability, and DoS traffic grows as a % of
internet traffic. Even gigabit wire-speed signing can be done now for
$reasonable, can 10gig be done? 100gig? Don't quite a few of the current
scaling techniques (e.g. anycast) scale badly with online signing? Aren't
the failure cases (e.g. hacked servers) rather worse? Doesn't this
fundamentally alter the security model rather more than NSEC (necessity
to put private keys on public servers).

Whilst I don't object to online signing being a w/g issue, it certainly
doesn't fulfil the "let's see if we can address the problem for
everyone" criterion I mentioned above.

So actually I agreed with most of what Ed wrote, certainly 1-4, 7-8.
I'm not sure I understood 9, 10 right. 10 seems to be a desire to
support forward upgradability that is absent throughout DNSSEC currently
(and sounds to me impractical, if not impossible, to change). 9 on the
otherhand sounds like mother's milk and apple pie. Do any ALT-NSEC
proposals *not* do this? Even the NSEC-epsilon stuff (see successor/
predecessor draft) seemed to spend a lot of time assuming that not
only single labels were supported.

Alex

---

From: [email-masked]
Date: Mon, 21 Mar 2005 11:22:27 +0000

> the hashes with an independent implementation and verify that it matches 

	ah... the rose coloured lenses...
	independent implementations are -VERY- hard to come by.
	esp. that have independent crypto libraries.  I've
	been told that building a "correct" crypto implementation
	is hard - and it is generally recommended to use an 
	existing, tested implementation.

> Ben.

--bill

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Mar 2005 12:01:20 +0000

> 	existing, tested implementation.

Speaking as one of the implementers of one of the more widely used 
implementations, I couldn't agree more.

By "independent" I meant "different existing tested implementation" :-)

As I noted elsewhere, I don't really believe faulty libaries is a 
problem in practice.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 21 Mar 2005 12:29:41 +0000

On 21 Mar 2005, at 09:08, Alex Bligh wrote:

> 10 seems to be a desire to
> (and sounds to me impractical, if not impossible, to change).

My comment below may well be totally daft, as I haven't done the 
reading.
If so, apologies all round.

OTOH, it may be "something we should have thought of" or even "an option
which is already available, and thus a strictly operational matter".

Is there any reason a zone owner wanting to introduce a "super-safe"
algorithm can't add a second set of signatures (per RR-set, I assume)
to the zone, so maintaining availability of the "commonly-considered-
good-enough" algorithm while "super-safe" acquires critical mass?

EUR 0.02

/Niall

---

From: [email-masked]
Date: Mon, 21 Mar 2005 13:06:16 +0000

> As I noted elsewhere, I don't really believe faulty libaries is a 

	er... recent posting from SMB in other fora indicates that
	design assumptions w/ one such library are posing interesting
	and unanswered questions about augmenting said libraries w/
	something other than SHA-1...  which begs the question of 
	what is a "faulty" library.  as usual, YMMV.  In any case,
	we have wandered afield from the DNS issues.  back to your
	regularly scheduled namedroppers threads.

-- bill

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Mar 2005 13:12:10 +0000

Edward Lewis wrote:
> The problem with demonstrating the closest encloser that is handled by 
> having to either include extra neg-answer records (to show that the 
> encloser identified is indeed closest) or to stuff in records at 

No records appear at empty non-terminals in NSEC3. Even if they did, we 
have already agreed that NSEC3 is effectively in a different namespace.

> Not having to mess with empty non-terminals,

You always have to mess with empty non-terminals in some sense.

> better handling of multi-label-depth zones.

Worse if you consider packet size to be a factor.

> If operations were so simple. ;)  I just see the existing documents as 
> overly concerned with the "science" and not operationally vetted.

That is certainly part of the point of getting operational experience, 
isn't it?

In any case, my long experience of crypto operations tells me that 
faulty libraries or hardware are almost _never_ the problem when crypto 
goes wrong. Mismatching public and private keys is a popular cockup, as 
is failure to correctly implement the application.

> implementation is free to generate negative answers in any matter it 

Because we see it as an interim solution, useful for testing and gaining 
deployment experience only, not one that we could actually deploy. 
Because of that, we don't currently intend to use it even in test, since 
that will be a pointless distraction from NSEC3, which solves the 
problem without all the issues that epsilon introduces.

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Mar 2005 08:53:28 -0500

>good-enough" algorithm while "super-safe" acquires critical mass?

I changed the subject because this is a tangent to authenticated denial.

There are two parts in answering this.

It is possible for a zone owner to supplement basic security by 
adding something stronger.  But supplementing means maintaining the 
older, "less safe" functionality.

For signing, I can sign with DSA and with some super-safe, 
super-secret private algorithm.  Most folks will use the former.  The 
problem is that I can't guarantee that the folks who should use the 
latter will do so - the server can't tell the client to "try this 
signature first."  For auth denial, if I want to employ NSEC42 
because it hides names correctly and I have to simultaneously do 
NSEC, the gain is lost.

Without a means for the server to tell the client what to use first, 
operational maintenance of updating all the concerned clients will 
undermine the organization that wants the protection.  Few enough 
people today understand the DNS protocol, fewer will be able to 
manage the detail of properly updating something as "insignificant" 
as resolvers.

The other point is that DNSSEC is not about the zone administrator, 
it's about the resolver.  It's the local policy at the resolver that 
matters most.  I think that this gets lost on us from time to time.

The resolver first has to understand new features, whether a new 
cryptographic library or a new algorithm for authenticated denial. 
Second, the resolver has to choose which of the approaches it knows 
that is to be followed first, then second, etc., until it drops into 
approaches not trusted to do the job (anymore).  What DNSSEC lacks in 
this regard is any means for the server to tell the client how to 
proceed - meaning it's really up to the resolvers to do the job 
"right."

So - when I see a phrase (and this isn't meant to poke at the poster, 
this happens commonly) like "a zone owner wanting to introduce," 
alarm bells go off in my head.  (Okay, with age I have the ringing in 
the ears, so this isn't a surprise.)  The alarms tell me that there's 
a desire to solve an impossible (IMHO) problem.  A well meaning 
desire, but one that will be fruitless (based on my experiences of 
trying something similar).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Mar 2005 09:14:06 -0500

>only single labels were supported.

9 refers to the comments that "white lies", the tag applied to 
answering with "false" names and signing responses on-line, breaks 
the security model of the DNS.  There was concern over the 
requirement (in dnssec-bis) that no name own just a auth-denail 
record.

The reason for the requirement in question dates back to the efforts 
to build the first signers and servers.  The requirement does not 
come from anything related to the resolver/verifier.

My faulty, beer-soaked memory recalls that I first thought of this 
requirement and sold it to others and it made it's way into text.  My 
recollection is that I was thinking only of server-side issues at the 
time.  My fear is that over time, repeated chanting of it has given 
this requirement more importance that it deserves and it has been 
taken to apply to the client too.

So Rant #9 refers to "white lies" isn't a problem.  It's not an 
aberration of the security model.  It's okay to cache the records 
just like any pre-calculated NSEC record.  That's where #9 going.

10 is just an overall "lack of feature" in DNSSEC.  Not a defect, 
just that DNSSEC doesn't have a mechanism for improvement on the 
base.  Barring negotiation of security parameters (and believe me, we 
DNSSEC-gray-beards did consider this) there isn't a good way to 
accomplish this.  Negotiated parameters were tossed as something that 
would kill the lightness of DNS.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Alex Bligh <[email-masked]>
Date: Mon, 21 Mar 2005 14:20:11 +0000

--On 21 March 2005 09:14 -0500 Edward Lewis <[email-masked]> wrote:

> 9 refers to the comments that "white lies"

Gotcha. Thanks.

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 21 Mar 2005 15:26:51 +0100

> Because we see it as an interim solution, useful for testing and 
> gaining deployment experience only, not one that we could actually 
> deploy. Because of that, we don't currently intend to use it even in 
> test, since that will be a pointless distraction from NSEC3, which 
> solves the problem without all the issues that epsilon introduces.
>

This statement worries me.

I was under the impression that "you and yours" were to deploy epsilon 
based techniques. Was I wrong, or did your ideas about deployment change?

I am also confused by the first and last sentence in the quoted 
paragraph. If you will not deploy it, not even in testing how would you 
gain deployment experience.

Paraphrasing Ed, in order to publish we'll need running code and 
deployment tests. I fully agree with that. Therefore I wonder if there 
is sufficient momentum to go forward with the epsilon based methodology 
if nobody will deploy anyway? In other words. Anybody on this list: 
would you deploy an epsilon based solution, with on-line keys, and no 
protocol change needed on the Internet or do y'all see this as an 
academic exercise?

I think it would be good to sort out what people are willing to deploy. 
If there is nobody even considering do deploy dynamic signing methods 
than I think we should just stop considering them as a viable 
alternative and waisting valueable working group resources.

--Olaf
  (hat in hand)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2005 15:43:43 +0000

> ...In other words. Anybody on this list: would you deploy an epsilon
> based solution, with on-line keys, and no protocol change needed on
> the Internet or do y'all see this as an academic exercise?

i don't think we can assume that the people who might deploy epsilon are
currently self-aware of that fact, nor currently on this list, nor both.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 21 Mar 2005 17:10:08 +0100

>currently self-aware of that fact, nor currently on this list, nor both.

Let me ask if you, and others on this list, are willing to put resources 
for making epsilon work for those that are not currently self-aware that 
they will be using the mechanism, nor aware of this work being done, nor 
both. Even if we fail to find the people who are self-aware that they 
will deploy epsilon and are on this list. :-)

I think that we are close to something useful that works and its not my 
suggestion to drop this work. It is just that my working assumption was 
that epsilon would be put to use by an identified party and that I would 
like to do a reality check on that assumption.

Personally I'm willing to burn resources on updating the proof of 
concept to a new version of the drafts.

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Mar 2005 11:10:07 -0500

>currently self-aware of that fact, nor currently on this list, nor both.

I ask rhetorically, who's fault is that?  If the folks on *this list* 
aren't the ones deploying this, why bother discussing it on *this 
list*?

Perceived problems are to engineers as imaginary gnats flying about a 
insane person's head.  All that flailing about and snatching at thin 
air.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Mar 2005 16:21:56 +0000

> based techniques. Was I wrong, or did your ideas about deployment change?

On reflection, we decided that since it was not going to answer our 
ultimate requirements, deploying it even for test seemed a pointless 
distraction.

We had never intended to deploy it in production. Our thought was that 
it might be useful in order to gain experience with the rest of the 
issues surrounding DNSSEC, but it doesn't seem likely to be any more 
useful any sooner than NSEC3 is for that purpose. So, we feel we should 
focus on NSEC3 at this stage.

Apologies for confusion, this was a conclusion we came to quite recently.

> gain deployment experience.

Deployment of DNSSEC, I mean. Which we will gain by deploying DNSSEC 
with NSEC3.

> deployment tests. I fully agree with that.

I also agree.

> Therefore I wonder if there 

See above.

> alternative and waisting valueable working group resources.

Agreed.

Cheers,

Ben.

---

From: Matt Larson <[email-masked]>
Date: Mon, 21 Mar 2005 11:52:22 -0500

On Mon, 21 Mar 2005, Olaf M. Kolkman wrote:
> Anybody on this list: 

"I encourage my competitors to deploy this solution."

Any form of signing on the fly is a non-starter for any VeriSign
DNSSEC implementation in com/net.

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2005 19:55:16 +0000

> Let me ask if you, and others on this list, are willing to put
> resources for making epsilon work for those that are not currently
> self-aware that they will be using the mechanism, nor aware of this
> work being done, nor both.  Even if we fail to find the people who are
> self-aware that they will deploy epsilon and are on this list. :-)

noone who helps ISC pay its bills has told me that epsilon would be useful.

> I think that we are close to something useful that works and its not
> my suggestion to drop this work. It is just that my working assumption
> was that epsilon would be put to use by an identified party and that I
> would like to do a reality check on that assumption.
> 

personally, i'd like to see epsilon developed further, and implemented, and
made into a viable option for NSEC-haters to use while waiting for NSEC3 to
settle out.  otherwise we'll see NSEC-haters sitting out DNSSEC-bis, which
is a problem since we're already facing serious nondeployment inertia.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Mar 2005 19:59:52 +0000

> aren't the ones deploying this, why bother discussing it on *this list*?

i thought this list was about the protocol, and that as stewards of the dns
protocol it was our job to make it useful for the entire community including
those who come after us.  let's not just "cash in" and try to turn dns into
something that's just-for-those-in-the-know.

> insane person's head.  All that flailing about and snatching at thin air.

and yet, had we involved nominet et al earlier on, then we would've known
that zone walking wasn't an acceptable tradeoff to get authenticated denial.
was it nominet's fault for not paying attention to us, or our fault for not
paying attention to them?  trick question!  it doesn't matter whose fault it
was, all that matters is we have a nondeployable protocol.  ouch!  "when in
a hole, the first thing you should do is stop digging."

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Mar 2005 16:23:58 -0500

>something that's just-for-those-in-the-know.

I fear my words were misunderstood.

Having seen protocols gain momentum over time, the eternal question 
is "how do we get the non-believers in the tent faster?"  Until they 
are in, we are just wasting time preaching to the converted.  This is 
a rhetorical question, because if we knew how to lure in the 
unsuspecting stake holders, we'd be luring now.

>a hole, the first thing you should do is stop digging."

Exactly what I've been saying, or trying to.