Subject: issues with draft-ietf-dnsext-dnssec-trans-00.txt

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 17:18:11 +0100

"2.1.1.4 Cons

    Unbalanced cost is a ground for DDoS. Though this protects against
    enumeration, it is not really a path for versioning."

This should also mention the security risk of the requirement for an 
online key.

"2.1.2.2 Limitations

    There are no technical limitations, though it will cause delay to
    allow testing of the (currently unknown) new NSEC interpretation.

    Since the versioning and signaling is done inside the NSEC RR, future
    methods will likely be restricted to a single RR type authenticated
    denial (as opposed to e.g. NSEC-alt, which currently proposes three
    RR types)."

Note sure I understand this - the presence of v2 of NSEC would signal 
that there are also NSECINFO and EXISTS records, wouldn't it?

2.2.2.4 Cons

Spello: role -> roll

"3. Conclusion

    The authors recommend that the working group commits to and starts
    work on a partial TCR, allowing gracefull transition towards a future
    version of NSEC. Meanwhile, to accomodate the need for an
    immediately, temporary, solution against zone-traversal, we recommend
    On-Demand NSEC synthesis."

We (that is, Nominet) can't at present imagine how we could deploy this. 
The problems we see are:

a) Invitation to DoS us, suggesting we'd need to investigate crypto 
offload devices.

b) Changes to software required, and hence a long period of validation 
and testing.

c) Exposure of private keys.

This sounds no easier to deploy in practice than NSEC2 would be, even if 
it didn't have problems that appear to make it unworkable in any case.

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

--
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: Jim Reid <[email-masked]>
Date: Thu, 10 Jun 2004 17:37:22 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    Ben> Note sure I understand this - the presence of v2 of NSEC
    Ben> would signal that there are also NSECINFO and EXISTS records,
    Ben> wouldn't it?

Not necessarily. Who can say now what NSECv2 will finally look like or
predict how many new RR types it'll need?

---

From: Alex Bligh <[email-masked]>
Date: Thu, 10 Jun 2004 20:25:14 +0100

> This should also mention the security risk of the requirement for an

Which you could add are of particular concern where not all secondaries
are under the same administrative control as the primary (whereas
with DNSSEC-bis this is irrelevant)

Alex

---

From: Alex Bligh <[email-masked]>
Date: Thu, 10 Jun 2004 20:33:41 +0100

> 3. Recommendation
>    On-Demand NSEC synthesis.

This may be stating the obvious, but some things this draft proposes are in
the nature of transition mechanisms of the protocol (e.g. TCR), and some
are in the nature of "things that can be done by those operators who find
enumberation problematic". For completeness, one thing in the latter
category that is not found in the draft but can be done by such operators
is "stick with non-sec DNS", and I suspect, where synthesis is not
practical, this may be the workaround of choice until -ter is available;
the advantages/disadvantages etc. sections should be obvious.

Alex

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 10 Jun 2004 22:00:42 +0200 (CEST)

On Thu, 10 Jun 2004, Ben Laurie wrote:

> We (that is, Nominet) can't at present imagine how we could deploy this. The 
> problems we see are:
>
> a) Invitation to DoS us, suggesting we'd need to investigate crypto offload 
> devices.

yes, crypto offload devices are needed. and if the crypto stuff performs 
close the normal query processing, DoS doesn't really count. if you add 
rate limiting and such to this, it's not be a problem.

> b) Changes to software required, and hence a long period of validation and 
> testing.

I believe adding support for on-demand nsec is way cheaper then adding 
support for any form of nsec2.

> c) Exposure of private keys.

you would use a separate set of keys for on-demand nsec signing.

> it didn't have problems that appear to make it unworkable in any case.

easier for whom? nsec2 has to be deployed everywhere and not just at the 
nominet nameservers.

if you can't deploy something based on nsec, waiting for nsec2 is always 
an option. if your domain holders care to wait that is.

 	jakob

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2004 23:44:40 +0200

> with DNSSEC-bis this is irrelevant)

I think this point should be emphasized more.  With the solution
dnssec-trans appear to propose, it is not enough to transfer a zone
file to a secondary, you must also transfer the private keys to all
secondaries, and keep the keys synchronized.  That is not a trivial
problem.  It is complicated further by considering the lose trust zone
administrators often have on the organizations running their slave
servers.  Typically they do not have any secure communication channels
between them.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 21:53:21 +0000

> ...  For completeness, one thing in the latter category that is not
> found in the draft but can be done by such operators is "stick with
> non-sec DNS", and I suspect, where synthesis is not practical, this
> may be the workaround of choice until -ter is available; the
> advantages/disadvantages etc. sections should be obvious.

for operators of enterprise zones this is a practical alternative.  for
operators of delegation-only or delegation-mostly zones where the subzones
are held by "registrants", this alternative is only practical if most of
those registrants are happy to be disconnected from dnssec in this way.

that's one of the driving forces behind the several known variants of
"islands of security", including the ihren-manning-kolkman "perl goo"
and also including conrad-vixie-kosters-weiler "dlv" (which is present,
though in an incomplete and as-yet-undocumented form, in 9.3.0-betaNN).

it's necessary, before an operator selects the "just don't bother with
dnssec until -ter comes out" alternative, to find out what impact that
will have (if any) on subdomain holders might care more about dnssec
than their superzone operator does.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 22:02:16 +0000

> > Which you could add are of particular concern where not all
> > secondaries are under the same administrative control as the primary
> > (whereas with DNSSEC-bis this is irrelevant)
> 
> problem.

and yet, this is a subset variation on what the ihren-manning-kolkman
"perl goo" does, and so this approach ought not be discounted on the
sole basis of its nontriviality.  it's possible that many nameserver
administrators will already be doing some kind of outofband keyrollover.

> It is complicated further by considering the lose trust zone

actually, typically these days, they do have such a secure channel, in
the form of a shared TSIG key used to control/authenticate AXFR/IXFR.
(an upcoming tool from isc leverages this trust relationship with what
we're calling a "metazone", which is why your statement caught my eye.)

---

From: Alex Bligh <[email-masked]>
Date: Thu, 10 Jun 2004 23:28:41 +0100

> those registrants are happy to be disconnected from dnssec in this way.

Sure - I wasn't make a policy point, I was just making the point that
draft-ietf-dnsext-dnssec-trans-00.txt omitted this possibility. Clearly it
has both pros (no alteration to -bis, implementation is hardly difficult!)
and cons (um, no DNSSEC functionality).

Alex

---

From: Alex Bligh <[email-masked]>
Date: Thu, 10 Jun 2004 23:47:05 +0100

(with apologies for replying to myself)

> with DNSSEC-bis this is irrelevant)

Hmmm... a random late night thought: would it be possible:
1. For the primary to sign the zone itself, with pre-synthesized NSEC
   records adjacent to all "real" records (which I am guessing would
   remove a substantial amount of load), then
2. either
   a) the secondaries synthesize only the remaining NSEC records (which
      perhaps could be prioritized differently in terms of response time);
      or
   b) the secondaries forward such remaining NSEC requests to one (or
      or more) primaries or false primaries under the administrative
      control of the zone operator (removing the need for key
      distribution). I am considering the ccTLD case where it is
      relatively common for some but not all secondaries to be under
      the administrative control of the zone operator.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:37:03 +0100

> predict how many new RR types it'll need?

I don't see why that matters - a resolver that understood NSECv2 would 
also understand the other RR types, and one that didn't, err, wouldn't.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:56:05 +0100

Jakob Schlyter wrote:

>> We (that is, Nominet) can't at present imagine how we could deploy 
>> this. The problems we see are:
>>

Rate limiting _is_ a problem since it causes lack of service.

> support for any form of nsec2.

I'll let you know what I believe when I've finished adding nsec2 support.

> you would use a separate set of keys for on-demand nsec signing.

How would that help? It would necessarily be a valid key for signing 
anything.

>> This sounds no easier to deploy in practice than NSEC2 would be, even 
>> if it didn't have problems that appear to make it unworkable in any case.
> 

Good point. Of course, for most people it is merely a matter of linking 
in a new version of the resolver library.

Cheers,

Ben.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 11 Jun 2004 11:20:40 +0200

>> yes, crypto offload devices are needed. and if the crypto stuff 
>> performs close the normal query processing, DoS doesn't really count. 
>> if you add rate limiting and such to this, it's not be a problem.
>

crypto performance outperforms query processing with a decent hardware 
accelerator.

> How would that help? It would necessarily be a valid key for signing 

yes, but only the private key used for on-demand nsec have to be 
distributed to all authoritative nameservers.

	jakob

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 11:33:04 +0100

> distributed to all authoritative nameservers.

Yes, but when it is compromised, the key can be used to spoof any record 
type.

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 12:41:39 +0200 (CEST)

> How would that help? It would necessarily be a valid key for signing

I use transaction signatures between my authoritative nameservers. That
implies I have online private or secret keys.

Issues with online private or secret keys are highly overrated, should be
kept in perspective and terms like 'Exposure of private keys.' are mere
propaganda.

You probably ment 'Exposure to private keys', but then, that is the
service that is offered :-).

Dynamic NSEC synthesis is currently the middle ground to satisfy both
sides of the spectrum where one side wants to deploy DNSSEC-bis as-is, and
the other side wants to deploy DNSSEC with defense against zone-traversal.

This middle-ground would be temporal until an upgrade is available per
Vixie's dnssec-ter proposal, where, again, both side of the spectrum are
satisfied.

I stick with the short and long term recommendation in the draft. I hope
it reaches consensus, so we can move on.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 11:55:04 +0100

> crypto performance outperforms query processing with a decent hardware

I am not disputing the point that this is a soluble issue but I am not sure
your point above captures the full picture. Many large zones are now using
anycast DNS (Nominet included). In this environment there could be far more
actual secondary machines than there are secondaries listed in the zonefile
(2 of Nominet's secondaries are provided by UltraDNS for example).
Therefore EACH secondary machine needs to have crypto accelerator hardware
which outpaces its ability to process queries (not each listed secondary
nameserver). So whilst the issue is soluble, it's soluble at cost (both
financial, and administrative - e.g. truckroll). This is afterall why one
of the original goals of DNSSEC was to avoid the need for online realtime
signing.

Alex

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 13:55:35 +0200 (CEST)

> of the original goals of DNSSEC was to avoid the need for online realtime

The cost of crypto-accelerator cards are a tiny fraction of the overall
DNSSEC deployment, support, production and management cost.

The investment in crypto-hardware is simply a three-year write-off, just
like the hardware its installed on.

Nominet charges 5 GBP per registration per year . With over 5M
registrations, that would be an annual turnaround of 25M GBP excluding
membership fees and non-membership registration fees.

A raise of .001 GBP on the 5 GBP registration covers 10 crypto-cards of
1500 GBP thank you very much.

Roy

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 11 Jun 2004 13:23:14 +0100 (BST)

> DNSSEC deployment, support, production and management cost.

Even with fast crypto hardware, isn't there still a problem of
significant asymmetry?  Normal operational loads could be easily
accommodated, but a malicious party should have no problem generating
sufficient levels of queries for non-existant domain names with the DO
bit set to overwhelm any practicable level of signing capacity.

Regards

Geoff

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 13:25:47 +0100

Roy,

> DNSSEC deployment, support, production and management cost.

I think you are disagreeing with something that I am not saying. I
expressly did not say the problem was insoluble. My concern was not that it
couldn't be done, but that the disadvantages should be fully documented in
the draft, and we should look at how to minimize the problems of synthesis
where there are a large number of physical secondaries not all under the
same administrative control (hence I suggested forwarding). I am quite
aware that the deployment, support, production and management costs are
likely to vastly exceed the hardware cost of crypto cards, and am thus
surprised that you compare costs against them below.

> Nominet charges 5 GBP per registration per year. With over 5M
> registrations

Actually 5 pounds per 2 years, closer to 4m paying registrations, and
rather more than 10 secondary servers if you include uDNS, but in any case
that's hardly the point.

My concern is (to relate this back to draft-ietf-dnsext-dnssec-trans-00.txt)
as follows:

The current -trans proposals suggest that the interim deployment solution
for DNSSEC that avoids enumeration requires online signing at each
machine acting as a secondary. This entails:
a) server software that is capable of doing it (and, in a situation
   where diverse software is used on secondaries) several sets of
   such software, possibly including development cost.
b) hardware acceleration do be provided on each machine such that its
   signing rate exceeds the query rate
c) what you characterize as "deployment, support, production and
   management cost".

None of the above is "not doable". However, I don't feel they are
fully documented in the current draft, nor do I feel the option of
"doing nothing (don't deploy)" is included. That would allow us
to spend all the effort, time (including development time) and
money we'd spend on (a) to (c), on developing and deploying -ter.

Or to put it another way, if -ter was approved ten days after -bis,
there would be no point deploying lots of crypto cards and writing
software to do synthesis, right? If it was ten years after, that
would change things rather.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 13:01:18 +0100

> it reaches consensus, so we can move on.

Consensus on that point would presumably require some people willing to 
implement it - are there any?

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 14:59:43 +0200 (CEST)

> surprised that you compare costs against them below.

Alex,

I responded specifically to:

   "Many large zones are now using anycast DNS (Nominet included). In this
    environment there could be far more actual secondary machines than
    there are secondaries listed in the zonefile (2 of Nominet's
    secondaries are provided by UltraDNS for example). Therefore EACH
    secondary machine needs to have crypto accelerator hardware which
    outpaces its ability to process queries (not each listed
    secondary nameserver). So whilst the issue is soluble, it's soluble at
    cost (both financial, and administrative - e.g. truckroll)."

The emphasis on EACH, the hint that multiple secondaries were hiding
behind anycasted addresses made me think you're looking for a
cost-multiplier to argue against crypto accelerator hardware.

There was no hint of text in your mail that dis-advantages should be fully
documented in the draft.

The problem is that stupidity is infinite, therefor covering every Bad
Idea including every advantage and disadvantage would be as infinite in
terms of work. Since I volunteered to write, I try to put a ceiling on
'infinite'.

> Actually 5 pounds per 2 years,

Okay.

> closer to 4m paying registrations, and

Oh, I got my information from:
   http://www.nominet.org.uk/Statistics/RegistrationStatistics/

Good to see that about 20 percent of the co.uk registrations are given
away for free. Other SLD/TLDs should follow Nominets example.

> rather more than 10 secondary servers if you include uDNS, but in any case

Let uDNS pay for their own shop, or get secondaries who do want to invest.

> fully documented in the current draft,

Current draft is informational. You don't need ANY wg-consensus to do
(a)(b) and (c). You need software to do this, but it doesn't require
inter-operable DNS standards.

If you would like to have a set of documents that entails all the ins-outs
of the synthesis hack, that can also be done without WG consensus.

> nor do I feel the option of
> "doing nothing (don't deploy)" is included.

Okay, will include that option in the draft. Send text please.

> That would allow us to spend all the effort, time (including development
> time) and money we'd spend on (a) to (c), on developing and deploying
> -ter.

You _really_ don't need wg-consensus, permission or a letter of intent
from any Standards body to do this. Honest.

> would change things rather.

Yes.

If you want to wait for -ter, that would be the good thing. That is what
we recommend in the draft ! If you can't wait that long, we recommend the
synthesis hack. If you can wait that long you have the option to "doing
nothing (don't deploy)"

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 15:09:10 +0200 (CEST)

> implement it - are there any?

To implement what ?

To implement the short-term solution which doesn't need ANY ietf-wg
action, consensus and so forth, you'd simply buy your feature from ISC or
NLnet Labs.

To implement the long-term solution which does need ietf-wg action,
consensus and so forth, you'd simply fund development of (pick your list
from http://www.rfc.se/fpdns/ ) combined with other TLDs or interested
partners who care for dnssec-ter.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 15:23:49 +0200 (CEST)

> bit set to overwhelm any practicable level of signing capacity.

There are first other ceilings (like bandwith, server performance) to
overcome if one suspects a possible crypto DDoS. This implies that a
simple non-crypto DDoS is just as easy to deploy, and the asynchronous
cost argument (for this particular use) disappears.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 15:26:21 +0100

> action, consensus and so forth, you'd simply buy your feature from ISC or

And decide that you don't care that you are spreading your private key 
all over the place, and find or build a crypto accelerator that does 
what you need.

> partners who care for dnssec-ter.

I am already working on an experimental implementation of NSEC2 in BIND.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:32:48 +0000

> > ...  Dynamic NSEC synthesis is currently the middle ground to
> > satisfy both sides of the spectrum where one side wants to deploy
> > DNSSEC-bis as-is, and the other side wants to deploy DNSSEC with
> > defense against zone-traversal.  This middle-ground would be
> > temporal until an upgrade is available per Vixie's dnssec-ter
> > proposal, where, again, both side of the spectrum are satisfied.  I
> > stick with the short and long term recommendation in the draft. I
> > hope it reaches consensus, so we can move on.
> 
> Consensus on that point would presumably require some people willing
> to implement it - are there any?

i don't expect isc's existing funding sources to think that this is an
important topic for us to spend effort on in the short term.  (the bind
forum seems to be more interested in performance and documentation and
usability than on advanced dnssec features, but that could change.)

however, new funding would bring its own rules.  so, theoretically at
least, there are some people willing to implement/prototype dnssec-ter,
subject only to resource availability.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 19:02:39 +0100

> Okay, will include that option in the draft. Send text please.

How about:

2.1.7 Do not deploy DNSSEC-bis

Do not deploy DNSSEC-bis; retain RFC1034/1035 non-secured nameservice
until DNSSEC-ter is deployable.

2.1.7.1 Coexistence and Migration

Current resolvers support and must continue to support RFC1034/1035
as must DNSSEC-bis resolvers. Assuming this requirement is cascaded
to DNSSEC-ter, there will be no coexistence issues. No migration
is required.

2.1.7.2 Limitations

It will not be possible for resolvers to authenticate any response.

2.1.7.3 Amendments to DNSSEC-bis

None required.

2.1.7.4 Cons

Does not meet requirements to provide authentication.

2.1.7.5 Pros

No additional software development required. No implementation burden
(assuming non-bis RFC2535 has not been deployed). Operational consequences
well understood.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 19:48:13 +0100

Roy,

> synthesis hack. If you can wait that long you have the option to "doing

On reflection, perhaps this is the cause of our misunderstanding eachother.

> On-Demand NSEC synthesis.

The last sentence is perhaps a little ambiguous as to what is recommended
when and to whom. Can I suggest that the sentiments in your mail would be
more clearly expressed in -trans as follows:

The authors recommend that the working group commits to and starts work on
a partial TCR, allowing graceful transition towards a future version of
NSEC to be incorporated in DNSSEC-ter. Meanwhile, for those for whom zone
traversal is problematic, but who have a requirement for authenticated DNS
which cannot wait for deployability of DNSSEC-ter, we recommend On-Demand
NSEC synthesis.

Alex

---

From: [email-masked] (Geoffrey Sisson)
Date: Sat, 12 Jun 2004 00:41:43 +0100 (BST)

> cost argument (for this particular use) disappears.

True . . . if plausible crypto acceleration solutions exist which are
capable of generating 40,000 NSEC RRSIGs per second, then admittedly
DoS attacks exceeding this rate would be close to exceeding other
operational thresholds.  With luck, the rate of improvement in
respective capabilities (crypto acceleration, bandwidth, server, etc.)
will not adversely affect this balance before -ter is deployable.

Regards

Geoff

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 16:46:37 +0200 (CEST)

> all over the place, and find or build a crypto accelerator that does

This is FUD.

Did you forget that private keys or secret keys are configured in online
machines to allow for secure zone-transfers ? Did you forget that SSL
requires an online private key ? Did you forget that SSH requires an
online private key ? What is then so enourmously special about SIG(NSEC)
private keys.

As an aside,

Do you understand that the trans- draft and dnssec-ter draft is done
SPECIFICALLY to accomodate the needs of Nominet and other interested in
defense against zone-traversal IN A NON-DESTRUCTIVE way ?

Roy

---

From: Ben Laurie <[email-masked]>
Date: Sun, 13 Jun 2004 11:41:03 +0100

Roy Arends wrote:

> machines to allow for secure zone-transfers ?

Only on one machine, and that one I can control carefully.

> Did you forget that SSL
> requires an online private key ?

Irrelevant: different threat model.

> Did you forget that SSH requires an
> online private key ?

It does not require a private key that can be used without my 
intervention, and again, its a different threat model.

> What is then so enourmously special about SIG(NSEC)
> private keys.

I'm not really interested in a huge digression about the design of 
secure systems, suffice it to say that Nominet has a variety of reasons 
to not want to deploy private keys on its DNS secondaries.

> defense against zone-traversal IN A NON-DESTRUCTIVE way ?

Of course I do - but this doesn't mean I have to agree with the first 
suggestion I hear, does it?

I still prefer the one/two record "deny everything" solution.

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Mon, 14 Jun 2004 09:14:00 +0200 (CEST)

> Only on one machine, and that one I can control carefully.

Zone-transfers require secret keys at both ends of the transfer.

> Irrelevant: different threat model.

It is not irrelevant wrt exposure, configuration, management and control.

> intervention, and again, its a different threat model.

Same joke, different name.

> to not want to deploy private keys on its DNS secondaries.

Ah, speaking for Nominet again. Handwaving like this does not help
in gaining sympathy and support for one's issues. ymmv.

> I still prefer the one/two record "deny everything" solution.

....

This says it all. Please go read the dnssec docs.

In short: with that solution, one could spoof responses to "deny
everything" under co.uk., AUTHENTICATED existing names, signed and
existing names, etc.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Mon, 14 Jun 2004 10:00:14 +0100

> everything" under co.uk., AUTHENTICATED existing names, signed and

& how is that worse than the likely alternative of "do nothing"?

Alex

---

From: Roy Arends <[email-masked]>
Date: Mon, 14 Jun 2004 11:11:44 +0200 (CEST)

> & how is that worse than the likely alternative of "do nothing"?

Far worse.

With "do nothing" (vanilla-dns) there is the same level of spoofing/MiM
behaviour wrt denial, though with the hack above, there is a signed record
that must be interpreted as "deny everything", which is signed by, yes,
nominet.

The effect is the same, though in the latter case of "deny everything"
there is a signature, created by a DNSKEY, which is bound to Nominet.

Now see (for instance) algroup.co.uk authoritatively and authenticatebly
denied by a record, signed by Nominet....

I also like the Do Nothing alternative, and we'll include your text in
-01.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 13:58:27 +0000

> & how is that worse than the likely alternative of "do nothing"?

if you do nothing, then paranoid clients will continue to have very
little confidence in spoofed data.  if you use a zone-covering NSEC
for all responses, then paranoid clients will have high confidence
in spoofed data.

not that i know of any paranoid clients, but we're all implicitly
assuming that there will be some, or else we wouldn't be doing dnssec.

i do not think that "a zone-covering NSEC" should be listed in -trans
as one of the alternatives.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Jun 2004 15:20:54 +0100

> I also like the Do Nothing alternative, and we'll include your text in

In what respect is this worse? So long as Nominet make it clear that 
such signatures are not currently meaningful, it has no impact.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Jun 2004 15:19:24 +0100

> This says it all. Please go read the dnssec docs.

Please don't assume I am an idiot, its rude.

> everything" under co.uk., AUTHENTICATED existing names, signed and

I know. This is no worse than the situation with unsecured DNS, surely? 
But it gives us a way to deploy DNSSEC in the interim without changing 
the spec and thus gain operational experience with it, pending the 
adoption of NSEC2 (or other solution to zone walking).

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Jun 2004 15:24:45 +0100

> Zone-transfers require secret keys at both ends of the transfer.

This is incorrect.

> in gaining sympathy and support for one's issues. ymmv.

I have already mentioned the issues. My point is that you think that all 
systems involving private keys have the same threat model, the same risk 
exposure and the same solutions. You are wrong, but explaining why is 
not on topic for this list.

Cheers,

Ben.

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 14 Jun 2004 16:29:37 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> (geoff, i'm not clear on how this proposal applies to NOERROR responses.)

Yes, this would likely not work properly if there were an owner name
match.  There would have to be an NSEC RR associated with every
authoritative owner name with a fictitious "Next Domain Field" entry.
Am I correct in thinking this is the essence of the "NSEC White Lies"
proposal in -trans?

> as one of the alternatives.

Is "zone-covering NSEC" worse than "do-nothing"?  In "do-nothing",
NOERROR replies can be spoofed; with "zone-covering NSEC", only
NXDOMAIN replies could be spoofed, which seems to have substantially
less potential for damage.

[ I realise "Dynamic NSEC Synthesis" is another answer, but this may
require nearly as long to deploy as -ter. ]

Regards

Geoff

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 15:54:07 +0000

> authoritative owner name with a fictitious "Next Domain Field" entry.

yes.

> Am I correct in thinking this is the essence of the "NSEC White Lies"

i think so, yes.

> less potential for damage.

security is of course not a single metric.  it's rare to be able to boil
the "amount of security" in two proposals down to single numbers that you
can then compare and say "proposal one has more security than proposal two."

however, according to the dnssec threat model as i understand it, we treat
"becoming confident, due to proofs, in something which is actually not true"
as having "less security" overall (or perhaps having "more insecurity") then
"not being confident, due to lack of proof."

therefore, "zone-covering NSEC" is worse than "do-nothing".  as a potential
author of a client for all this technology, i'd much rather face a condition
where i know what i don't know, then one where i don't know what i know.

---

From: Peter Koch <[email-masked]>
Date: Mon, 14 Jun 2004 17:53:18 +0200

> Am I correct in thinking this is the essence of the "NSEC White Lies"

exactly.

> less potential for damage.

This is difficult to answer as it depends on one's expectations. In "do
nothing" we know it can happen, whereas in DNSSEC-bis we ``know'' it can't
happen. That's why NSEC white lies needs an agreed upon signalling method
which shouldn't need any new bits/flags.

-Peter

---

From: Alex Bligh <[email-masked]>
Date: Mon, 14 Jun 2004 17:18:30 +0100

> for all responses, then paranoid clients will have high confidence

Which is one reason why it would be good if there was some signaling
that denials should not be treated as authenticated: as Peter Koch

> which shouldn't need any new bits/flags.

even if only one particular form of zone-covering NSEC record, e.g.
	\001	IN	NSEC	\001

Alex

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 19:45:44 +0200

Paul Vixie <[email-masked]> writes:

> therefore, "zone-covering NSEC" is worse than "do-nothing".

I don't understand this argument.

To evaluate a solution against a threat model, I believe the metric
you should use is what an attacker can and cannot do, given different
capabilities.

Here is simple evaluation:

In DNS, an active attacker can spoof anything, but positive and
negative responses, and cause DoS.  A passive attacker can't do much,
besides perhaps gathering query id information which can be used later
in an active attack, because the data sent is not confidential.

In DNSSEC an active attacker can cause DoS.  An active attacker cannot
spoof positive responses -- any correctly implemented resolver will
not be able to sign the signatures to a trusted root.  An active
attacker cannot spoof negative responses -- only data for which a
successfully verified NSEC exist will be authenticated as
non-existing.  For a passive attacker the situation is similar as
before, with the possible addition of being able to read ciphertext
for keys she may want to crack.

In DNSSEC with NSEC-lies, an active attacker can cause DoS.  An active
attacker cannot spoof positive responses.  An active attacker can
spoof negative responses, by replaying the lying NSEC.  For a passive
attacker the situation is similar as the previous case.

If you can show that with DNSSEC-with-NSEC-lies an active attacker can
spoof positive responses, you may have a case.  Otherwise, I believe
the conclusion is simple, if evaluated from the above perspective:
DNSSEC-with-NSEC-lies is an improvement to vanilla DNS.

It is possible, and useful, to go into more detail by differentiating
among the capabilities of active attackers: generic active attackers,
cache poisoning attackers, etc.  But I believe the DNSSEC threat model
include generic active attackers, so any less capable active attacker
is included in the generic active attacker.

> as a potential author of a client for all this technology, i'd much
> rather face a condition where i know what i don't know, then one
> where i don't know what i know.

DNSSEC doesn't guarantee data correctness, never has.  It guarantee
that what you see is the same as what the publisher of the zone wants
you to see.  If this include lying NSEC's, this is what you will see.

Regards,
Simon

---

From: Derek Atkins <[email-masked]>
Date: Mon, 14 Jun 2004 15:30:01 -0400

> DNSSEC-with-NSEC-lies is an improvement to vanilla DNS.

They cannot forge a new positive response to replace the real positive
response, but they can replay the lying-NSEC and cause the recipient
to believe authentically that there is no positive response to their
query even when it exists.  All they need to do is make sure the NSEC
replay is received and suppress the positive response.  So I suppose
this is just a DoS attack, but it's a DoS attack that does not exist
in normal DNSSec (nor with DNSSec with real-time signed NSEC).

In other words, an attacker could effectively authentically deny the
existence of all nodes in your zone covered by the lying NSEC records.

> is included in the generic active attacker.

This is correct.

> you to see.  If this include lying NSEC's, this is what you will see.

Right, but with lying NSEC you are not guaranteed that you'll receive
all the data.  A real positive response could be dropped in transit,
and with normal DNSSec you can detect this, but with lying NSEC you
cannot.

> Simon

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 22:21:49 +0200

> in normal DNSSec (nor with DNSSec with real-time signed NSEC).

But compared with vanilla DNS, the situation is the same.  So I
couldn't follow how DNSSEC with lying NSEC's is worse than vanilla
DNS.  Compared to full DNSSEC, naturally DNSSEC with lying NSEC is
worse, but I doubt anyone thought otherwise.

Of course, being able to spoof that something doesn't exist is worse
than one might first assume; missing MX records can redirect e-mail.

Thanks,
Simon

PS. There were at least two typos in my post quoted above; `but
positive and negative' should have been `both positive and negative',
and `sign the signatures to a trusted root' should of course have been
`verify ...'.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 20:57:56 +0000

> that denials should not be treated as authenticated: ...

if you want non-authenticated denial, maybe you should just leave out
the NSEC altogether.  putting your signature on one that covers names
which actually exist, and then leaking that signed "lie" to the universe,
where others could replay or misinterpret it out of context, seems like
a huge mistake to me.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 14 Jun 2004 20:37:19 -0400

On Mon, 2004-06-14 at 16:57, Paul Vixie wrote:
> the NSEC altogether.

I think at that point you may as well not answer the question.  If your
zone has a key, an unsigned response looks like an attack, and should be
discarded.

I kind of like the deny-the-whole-zone NSEC response, personally.  The
denial replay attack seems like a relatively mild practical
consequence.  (Of course, I think it's much better to have real NSEC
records and a zone file available for FTP, and I think most of the
arguments against doing that are horribly off the mark, but I'm willing
to take it as axiomatic that some zones will find denying enumeration
more important than having good security against spoofing attacks.)

---

From: Don Stokes <[email-masked]>
Date: Tue, 15 Jun 2004 15:18:31 +1200

>than one might first assume; missing MX records can redirect e-mail.

MX is the obvious case where spoofed authenticated denial could be used
in a non-DoS attack.  Anything that has some kind of fall-back will be
vulnerable, including use of search lists for partial name lookups,
low-priority SRV records etc. 

-- don

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Jun 2004 13:02:46 +0100

> where others could replay or misinterpret it out of context, seems like

This would work for me - but will resolvers be happy with such a response?

Cheers,

Ben.