Subject: Re: DS and Opt-in - a proposal

From: [email-masked] (Ted Lindgreen)
Date: Sat, 12 Jan 2002 19:28:30 +0100

[Quoting Roy Arends, on Jan 12, 18:33, in "Re: DS and Opt-in -  ..."]

> Factor of 2 in numbers, which result in an order of magnitude in
> size.

Please, make that, taking glue into consideration: in the worst case
less or much less than a factor of two, going to nil difference as
implementation progresses.

As for size:
> Lets put in another small variable called Q in your formulae. Q stands for

Ok, I bear with you...

> WHOA, factor 10, order of magnitude....

Interesting, but now I get a bit confused reading on, about your
own real life experiment:

> btw, last year at NLnet Labs, signing a .com zone increased the bare
> zonefile with factor 4 (ascii file, not the file in core).  Signed by a
> single 768 bit DSA key. This took about 71 hours including sorting,
> without certified crypto-hardware or software.

so, the ascii size  increased a factor of 4, please explain, perhaps
Q above is a little exaggerated? And, also, that experiment was done
before DS was invented, if I recall correctly.

Another remark about size, I think that's less relevant as memory
and bandwidth availability has increased faster than CPU power over
the years.  Therefore, I can understand that a steep increase  in
CPU workload ( ~ nr. if RRs) hits Moore's Law a lot sooner than an
increase in average RR size.

-- ted

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Roy Arends <[email-masked]>
Date: Sat, 12 Jan 2002 20:35:46 +0100 (CET)

On Sat, 12 Jan 2002, Ted Lindgreen wrote:

> Q above is a little exaggerated?

No, Q was merely: approx 150 bytes for a SIG RDATA compared to approx 15
bytes for a NS RDATA (is 10 to 1) times 3 Signatures per signed RRset.
That is 30 to 1 amount of signature RDATA to NS RDATA for each signed
RRset.

But then there is lies, damned lies and statistics.

> And, also, that experiment was done before DS was invented, if I
> recall correctly.

Yes.

All that, still 71 hrs of sorting & signing, for a zone that denies
security for every individual delegation.

With OptIn it would probably be 3 hrs of sorting, and ehhh, that's it. Try
that for a factor (71:3). That factor would slowly decrease with the
adoption of DNSSEC.

> increase in average RR size.

Fine, lets assume that for a second, still it would be far more scalable
to do a rollout with opt-in then without, while the change in security
model hardly hurts, as been said a number of times.

Roy Arends
Nominum

---

From: Derek Atkins <[email-masked]>
Date: 12 Jan 2002 15:11:40 -0500

> That is 30 to 1 amount of signature RDATA to NS RDATA for each signed

Let's ignore plain 2535.

Where do you get 3 Sigs per RRset?  There is SIG{NXT} for each record,
sure.  And for the secure children there is SIG{DS}.  That's 1+X.
Where is this third signature coming from?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Derek Atkins <[email-masked]>
Date: 12 Jan 2002 15:59:15 -0500

Roy Arends <[email-masked]> writes:

> I was assuming that one will sign a zone with more then one key, which
> will create more then one signature. If I want to do a scheduled key
> rollover, then at some point before the rollover date I signed the zone
> with 2 keys, and after the rollover with 2 keys, while the two signing
> events share at least one key. To smoothen the rollover, I'll sign with 3
> keys.

Ok, so the steady state of DS is (1+X)*S, with local maxima of
(1+X)*2*S during (infrequent) times of key rollover.

> Example:
> 
> at point 1, there are 2 keys, key A and B. Now, I want to roll key A over
> to key C.

Why would you have two keys at any particular steady-state time?
Sure, you need a second key during a rollover, but that does not mean
you need to keep around a second set of signatures at all times.

-derek

---

From: Roy Arends <[email-masked]>
Date: Sat, 12 Jan 2002 21:40:16 +0100 (CET)

Example:

point 1 | point 2
key A   | key C
key B   | key B

To make sure I have some redundancy, I start signing the zone with key C
_before_ I'll discontinue key A, so I would have

point 1 | point 2 | point 3
key A   | key A   | key B
Key B   | key B   | key C
        | key C   |

At point 2 I would have 3 different keys. IMHO this would be a real
situation. I have seen setups with a 5 keys, where 1 would roll-over as
follows:

pX is some point in time,
kX..X+4 are the set of current keys at pX

p1 p2 p3 p4 p5
--+--+--+--+--
k1|k2|k3|k4|k5
k2|k3|k4|k5|k6
k3|k4|k5|k6|k7
k4|k5|k6|k7|k8
k5|k6|k7|k8|k9

Assuming a single key, no matter how strong, for a zone as critical as
com, without rollover mechanisms like above, is IMHO bad practice, that is
why I calculated in more keys.

Regards,

Roy Arends
Nominum

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Jan 2002 13:20:40 -0800

gentlefolk, when all is said and done about how hard or easy non-opt-in is
to sign, transfer, or serve, other more relevant facts will still hold sway.

that's that verisign will not sign .COM until they want to.  nobody, not DoC
or ICANN or IANA or certainly not IETF is going to somehow argue them into it.

so you can prove that it's possible to do it all day long, but their
conceptions, even irrational preconceptions, will still hold sway.

so please, let's all stop flapping our gums and explaining the math of it,
because this is not a math problem.

if we were otherwise ready to roll out dnssec i'd say tell verisign to go
pound sand.  (and in fact, i did say this, when i thought dnssec was 
otherwise ready to roll out.)

but since we're doing DS with a non-backward-compatible flag day, we're not
talking about holding up dnssec to get opt-in in (which would be stupid, and
which we wouldn't do.)

that makes this more like a first-principles discussion, as in "would we have
done it this way in the beginning if anybody had thought of markk's opt-in
idea in the beginning?"  my answer is: YES.  this is the right way to do
dns security.

if anybody wants to have a relevant discussion about this, that's where to
begin.  the math isn't relevant and never was.  verisign's desires aren't
relevant and never were.

---

From: Roy Arends <[email-masked]>
Date: Sun, 13 Jan 2002 14:09:56 +0100 (CET)

On Sun, 13 Jan 2002, Olaf Kolkman wrote:

> PS: I am still afraid, and I know that is a social argument, that
> with having OPT-IN available on all levels of the tree we will end up
> with only a few RRs signed, the DNS as a system will loose that way.
> The argument that 'people can use opt-in to circumvent NXT walks' is a
> good incentive to have zones with only their www.companyname.com name
> signed. All the other data in the DNS would remain unsecured,
> spoofable etc. etc.

I rather sign nodes in my domain because I want to, not because I
must.

Note: as said, also with 2535+DS it is possible to have just
www.companyname.com signed and the rest not.  However, a helluva lot more
work, so the rest is signed because it has to (i.e. choosing the lesser
of two administrative evils).  That, to me, is silly.

I've a lock on the front and back door of my house.  That is by choice.
I will protest if I must have locks on every door, including the
kitchen-sink.

Opt-In offers a choice.  Some may not like that choice.  I do.

Roy Arends
Nominum

---

From: Derek Atkins <[email-masked]>
Date: 13 Jan 2002 11:13:59 -0500

> I rather sign nodes in my domain because I want to, not because I

And if everyone in the universe gets this choice, we wont be any
better than we are now, because nobody is willing to go to the
extra effort to add security if they don't have to.

When it comes to scurity, choices are a Bad Idea (TM).  The more
choices you have, the more possibility you have to shoot yourself
in the foot.

-derek

---

From: Olaf Kolkman <[email-masked]>
Date: Sun, 13 Jan 2002 13:16:27 +0100

* I was assuming that one will sign a zone with more then one key, which
 * will create more then one signature. If I want to do a scheduled key
 * rollover, then at some point before the rollover date I signed the zone
 * with 2 keys, and after the rollover with 2 keys, while the two signing
 * events share at least one key. To smoothen the rollover, I'll sign with 3
 * keys.

This statement does not hold with DS. ( So there are no unexpected
peaks in the size because of key-rollover in a 2335-DS only scheme )

Argument:

You use a production key to sign your records, that one is signed by
the a master key.  At rollover of the Master key you need to have a
signature of the apex keyset with both old and new master key.

With DS you can also rollover your production key without having
double signature. You just need to have a signature over the new key
made well in advance (at least one TTL of the apex keyset before you
resign with the new key).

So in 2535+DS+NXT you can securely manage your zone with only having 1
additional signature per unsecured delegation and 2 additional
signatures with a secure delegation. 

By the way:

A back of the envelope guestimate shows that for a name length of 'i'
bytes the zone size of a zone dominated by unsecured delegations with
2 NS records and 2 glue records per delegation the zone size grows as:
(9*i+j)/6*i where 'j' is the byte size of the signature. Which for
reasonable signature length and reasonable label sizes is about a
factor 3 to 4.

I can't speak for G|TLDs but I think most of them will be able to cope
with that.

--Olaf

PPS: Input for the guestimate: 

Take size of RRset to be '2*i' for a NS record, 'i' for an A record,
'2i' for the NXT record and i+j for the SIG. Assume two NS records and
two glue A records per delegation.

growth:
>From N* (2*(2i) + 2*i)=6i
to   N* (2*(2i) + 2*i +2i + i+j)=9i+j

---

From: Paul Vixie <[email-masked]>
Date: Sun, 13 Jan 2002 09:25:27 -0800

> > I rather sign nodes in my domain because I want to, not because I must.
> 

there's an undercurrent of father-knows-best running through this thread.
and it's starting to appear that this, rather than pro/anti verisign
sentiments or any kind of law of math or physics, is at the heart of the
debate.  let me test this by adding a thread on the issue of paternalism.

--------

dns is a distributed, coherent, autonomous, reliable database.  (the only
one of its kind in the history of our kind.)  let's focus for a moment on
"autonomous" by contrasting dns against RFC952 (HOSTS.TXT) at the instant
that the owner/provider of a network resource desires that resource to gain
a universal (coherent; unique) name which has more meaning than its IP
address and/or port number.

with RFC952, the next step was to involve another party -- SRI-NIC.ARPA,
who would register your universal identifier in a global shared database
(HOSTS.TXT).

with RFC1034, the next step was and is entirely a local matter: you edit
the zone which covers the part of the namespace you're adding a name to,
and you instruct your DNS server to publish this new zone.

this is what "dns autonomy" is about.  the only time you ever have to
involve another party in your naming work is when delegating new zones or
changing the delegation of an existing zone, if and only if you are not
also the owner of the delegating (parent) zone.

--------

much has been said in the opt-in debate about "changing the security model,"
from a common understanding that such changes if any must be carefully
understood and not adopted as an unanalyzed side effect of some seemingly
compelling change.

i propose that opposition to dnssec opt-in on the grounds that other zone
owners ought not have this choice available to them is "changing the dns
autonomy model" and ought receive the same level of analysis and concern.

at the moment, the dns autonomy model is that one only needs permission from
a second party when you want that party's zone edited to add or change a
delegation of one of your zones.

dnssec + ds adds key management to delegation management but does not
add more parties to the list of "who can control what data a zone owner
wants to see published."

opposition to opt-in on the grounds of preventing "too many choices" seems
to imply that "the set of all resolver owners" ought to have the ability
to control what a zone owner is allowed to publish.

--------

i think that anyone who secures less than they could secure is being silly.
but i recognize the autonomy of zone owners and i cannot in good conscience
try to force them to publish what i want instead of what they want.

an unsecure answer under the opt-in plan has the same security status as it
has without dnssec at all.  resolvers can believe it or not, as they please.
there is no new transaction mode where you get something you think is secure
that really isn't as secure as it could be -- that is, when you get something
that isn't secure, you know it.

why are any of you here willing to take a stand that "the owner of VIX.COM
ought to have to swallow the whole DNSSEC pill or get no authenticity at all"?
it's my zone.  what part of it is secure ought to be my decision.  whether
it is secure at all ought to be a decision i share with the owner of COM.
so, what business do any of you have butting into my affairs in this way?

(note that i'll sign the whole thing, without opt-in, as soon as possible,
but that that has to be my choice, not your choice, or we'll have to fight.)

in legislative matters, this dispicable behavior is called "attaching a rider"
and is a form of passive aggression.  "you can have the part of this you want
if you also take this other part that you really don't want."  a bet is made
by the attacher that 

chances are nonzero that the impact will simply be that folks move a lot of
their unsecurable content into different zones.  or won't use dnssec at all
because its deployment cost is too high.  especially as they'll know that the
cost was made artificially higher for reasons of security model purity.

changes to the security model can't implicitly call for changes to the
autonomy model.  if we're going to change the autonomy model, let's do it
with our eyes open.  or preferrably, let's not change the autonomy model,
but rather, let's make the security model work under the existing autonomy
model.  because there is no place for paternalism in protocol design.

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Jan 2002 09:47:38 -0800

> debate.  let me test this by adding a thread on the issue of paternalism.

this discussion is hard enough already.  let's not drift into who acts how
and who loves whom, please.  thanks.

randy

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 13 Jan 2002 09:58:33 -0800

> and who loves whom, please.  thanks.

then you must disallow all arguments of the form "whether or not a distant
zone editor is able to choose which of their subdomains to authenticate is
something i care about for reason XYZ."

i don't think you could or should do that.  it is easier to have this
argument than to try to prevent it.

---

From: Derek Atkins <[email-masked]>
Date: 13 Jan 2002 13:41:00 -0500

> argument than to try to prevent it.

You can choose not to authenticate a child zone.  That is not the
issue at hand.  The quesiton is whether you can only authenticate
part of a zone, and I think that the cut should be at the zone level.

If you want to go through the extra step to make an unauthenticated
portion of your network, you are more than welcome to do so.  There is
a very well-defined mechanism for doing so.  We don't need Opt-In to
make it possible.

-derek

---

From: Paul Vixie <[email-masked]>
Date: Sun, 13 Jan 2002 11:08:30 -0800

> part of a zone, and I think that the cut should be at the zone level.

...for all zones, no matter what the wishes of the owners of those zones.

> a very well-defined mechanism for doing so.  We don't need Opt-In to

...as long as the zone owner is willing to split her zone and thus split
her namespace in order to maintain this security model purity.

if dns is a distributed, coherent, reliable, autonomous database, then
will we now sacrifice "autonomous" in order to add "secure", resulting in
a distributed, coherent, secure, reliable database?

that may seem to some assembled here to be "a small thing".  maybe it is
a small thing (even though i don't think it is a small thing) but if so
then its smallness should be debated in its own right, and not be some
kind of implicit comealong.

taking away some autonomy in order to add some security is antithetical
to most internet services, protocols, and communities as i understand them.

"whose zone is it, anyway?"

---

From: Derek Atkins <[email-masked]>
Date: 13 Jan 2002 14:22:49 -0500

Paul,

There are tons of "rules" that DNS operators must live by:

 - A records must be of a certain form, and must be sent on the wire
   in a certain form.  Same for every other record.  Why can't you
   send data in any format you wish?

 - Node names are limited to a subset of ascii.  Why can't you include
   any character that you want in your node names?

 - Host names must begin with an alpha character.  Why can't I have a
   host named "1234"?

There are tons of rules.  We have to live by them.  They exist to
make sure there is a clear understanding between the person that
puts the data into the system and the person that is using that
data at the other end.

DNSSec is just like this.  It is a data format requirement.  It's
not saying anything about _what_ you put in the DNS.  It's just
saying _HOW_ you must put it in the DNS.  You are still free to
name your hosts whatever you want, put whatever information you
care to in your zone.  But if you want to provide authenticated
information, this is how you do it.  I don't see a problem with
that.

-derek

---

From: Olaf Kolkman <[email-masked]>
Date: Sun, 13 Jan 2002 20:13:36 +0100

* I've a lock on the front and back door of my house.  That is by choice.
 * I will protest if I must have locks on every door, including the
 * kitchen-sink.
 * 
 * Opt-In offers a choice.  Some may not like that choice.  I do.

<semi-serious analogy with smiley>

But your insurance company may force you to secure the kitchen sink
door to make the system of houses as a whole more secure.

</semi-serious analogy with smiley>

Enabling more granularity makes the system less secure. 

I am not worried about OPT-IN at TLD level but for OPT-IN deployed at
the end nodes.  As mentioned before an "OPT-IN" that would not allow
granularity on anything else but delegation records would solve my
worries.

The restriction would be worded something like: "Any name (key)
in the DNS that has only NS RRs MAY not have a NXT (opt-in style)
RR. Any other RR MUST have a NXT RR."

This allows deployment in large G|TLDs and disallows the use of OPT in
at end-node zones, providing fully secured zones. The complexity added
is IMHO not prohibitively expensive.

--Olaf

---

From: Derek Atkins <[email-masked]>
Date: 13 Jan 2002 14:16:33 -0500

> is IMHO not prohibitively expensive.

What about glue A records at the TLDs?

-derek

---

From: Olaf Kolkman <[email-masked]>
Date: Sun, 13 Jan 2002 21:22:19 +0100

It's Sunday night, after a corpulent dinner I might have lost
coherency in the argumentation, but let's give it a try.

 * opposition to opt-in on the grounds of preventing "too many choices" seems
 * to imply that "the set of all resolver owners" ought to have the ability
 * to control what a zone owner is allowed to publish.

There are two parties that can make choices here. The zone holders and
the resolver holders. Your arguments for the autonomy for zone holders
is clear. But the resolver owners also have their autonomy.  Resolver
holders may choose not enable to enable security on their systems if
there is to little data signed or if it is to expensive to
troubleshoot problems.

I am afraid that the incentive for resolver operators is not as high
if only a few names in the DNS are secured; in an OPT-IN world that
would be the case because the autonomy and the freedom of choice
exists. Then again, in a non-opt-in world one could argue that
resolver operators would not turn on security as long as it is not
deployed in .com.

I always thought that DNSSEC was designed to secure the DNS system as
a whole. I would say that is something as a 'public good'. Not
allowing the granularity introduced with opt-in would be of public
interest but limits individual choice. 

Isn't it 'Politics' that is about finding the proper balance between
public good and individual choice ;-) . Since the IETF is (should) not
(be) doing politics it should not be trying to define the balance
between 'choice' and 'good'. The balance should have been defined in
the requirements. I have still not extracted the answer from the
requirements but always understood that the system as a whole needed
securing. Hence my (repeating) argument about not adding granularity
or freedom of choice as others call it.

--Olaf 

(I will try not to repeat myself in the future.. :-) )

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Jan 2002 12:25:33 -0800

> Enabling more granularity makes the system less secure. 

and harder to know what security one has

randy

---

From: Olaf Kolkman <[email-masked]>
Date: Sun, 13 Jan 2002 21:13:21 +0100

Derek Atkins <[email-masked]> writes:

 * What about glue A records at the TLDs?
Those should be left alone... just as in 2535. 

"All data for which the zone holder is authoritative MUST have a NXT
record.  The NXT record MAY be used to authoritatively indicate that a
delegation exist and is insecure."

I think this formulation works since a zone is not authoritative for
delegation NS and Glue. Each secured delegation would add a DS record
for which the parent zone is authoritative, so the NXT must be present
by virtue of the DS RR.

The "MAY" clause reflects the "NULL key", providing authenticated
denial of security for the child zone.

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Sun, 13 Jan 2002 13:57:33 -0800

> There are tons of "rules" that DNS operators must live by:

yes indeed, we must follow the protocol or we risk not being understood.

i am not arguing for the freedom to deviate from the protocol, because
that would be meaningless.  protocols, to be useful or meaningful, must
be followed.

(your examples were flawed in their details: names should not be
completely numeric outside of in-addr.arpa but are allowed to start with
digits; and, the protocol spec actually says you can send 8-bit data in
name fields, but sloppily forgets to explain what non-ascii means at the
presentation layer.  however, this discussion doesn't depend on the
accuracy of your examples -- let's just agree that we have to agree
follow the protocol in order for it to _be_ a "protocol".)

however, we're not in agreement as to the actual point under discussion,
which is subtly different from whether we all plan to follow protocols.

> information, this is how you do it.  I don't see a problem with

nothing else in the protocol (which we all agree to follow, or else it
won't _be_ a protocol or at least not a relevant or active one) attempts
to ram policy down a zone owner's throat, even to the point of removing
or limiting features that a protocol designer thinks would be bad for the
internet.

to pick one of your examples, the reason multilingual names didn't work
on day 1 is that nobody who was doing the work cared enough to do all
the hard definition-level work that we now see in the IDN WG.  *NOT*
because we thought multilingual names were a bad idea and that the whole
world ought to be using 7-bit USASCII.

leaving a proposed feature out is sometimes (often!) the right thing to do.
"good" reasons for doing this include:

	expect it to take a lot of work and there's no volunteer

	expect it to take a lot of time and we don't want to wait

	nobody's asking for it except dwellers in some ivory tower

	there are workarounds that cost less than the added complexity

what i'm seeing in the paternalistic debate pattern here is a "bad" reason:

	we don't think the internet ought to be allowed to work that way

"whose zone is it anyway?"

paul

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 14 Jan 2002 15:03:36 +0100

On Sun, 13 Jan 2002 12:25:33 -0800

> and harder to know what security one has
Rephrasing an idea so that it stands out a little more.

DNS administrators and users have all learned to deal with the concept of
zones. In the DNS changes appear at zone cuts.  Let's keep things easy for
the troubleshooters and not allow 'security' changes within zones.

If we allow for OPT-IN over delegations only we solve the apparent
large zones problem and we keep security at zone levels.

Suggested wording for the draft:

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 14 Jan 2002 14:38:27 -0500 (EST)

<chair hat off>

> large zones problem and we keep security at zone levels.

This argument has been made before (by Olaf and myself) and has been
pushed back by the advocates of opt-in and some others.
The  effect of opt-in is to create a "selective security" for any name in
a DNS zone.

The argument that I want to make is about the maintainance of
zone with some names secured and some insecure, has the potential to
be an administrative nightmare, as there must be an indicator for each
name (or sequence of names) that indicates when to sign and generate NXT.

Background: RFC2065 and RFC2535 allow any authoriized key to sign DNS data
at and below that name, RFC3008 outlawed this and restricts signatures to
zone key residing in at the top of the zone.

The cost of supporting this choice was to add $SIGNER directives all
over the zone file, frequently resulting in the attempt to sign data with
the wrong key. Verifying the data was much harder as more keys where
allowed  to sign the data (apex zone key and some user/host keys).

If only delegations can are covered by opt-in then it is simpler, opt-in,
any delegation that has DS is signed, only insecure delegations that are
to be signed need an flag to trigger signing.  For organization like
Verisign that generates their zone files from a backend database system
and prefer to generate the appropriate NXT outside the signing tool,
supporting Opt-in is trivial, but for the people that use standard flat
text files things get harder.

The fewer execptions features we allow, the better off we are in
the long run.

Is there anyone else out there that supports Olaf's position ?
If Olaf and I are a minority of two,  I will shut up about this.

> delegation exist and is insecure."

Slightly different wording:
All names in a secure zone that have signed records MUST have a signed
NXT, delegations MAY have a signed NXT to indicate that they exist and
are insecure.

	Olafur

---

From: [email-masked]
Date: Tue, 15 Jan 2002 11:35:49 +1100

> If Olaf and I are a minority of two,  I will shut up about this.

	I think it is a reasonable compromise.

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Jan 2002 14:56:31 -0800

> NXT, delegations MAY have a signed NXT to indicate that they exist and

so, you are trying to kinda help authenticated denial.  but, if the resolver
does not know if the zone has NXTs for the insecure delegations or not, then
the information seems not too useful.

randy

---

From: Greg Hudson <[email-masked]>
Date: Tue, 15 Jan 2002 00:47:50 -0500 (EST)

> the information seems not too useful.

I believe you're missing (because Olafur glossed over it) that the NXT
records would still contain the bit saying whether or not the domain has
NXT records for insecure delegations.  That's already in the opt-in
specification.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jan 2002 23:25:35 -0800

> NXT records for insecure delegations.  That's already in the opt-in

so the opt-in status of the zone (not domain) is itself optional?

this raises the complexity to a new level.  is there payback for this?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jan 2002 23:21:43 -0800

> 	I think it is a reasonable compromise.

well maybe, except it isn't enforceable.  if someone somewhere decides to
implement their NXT's without this restriction, the encoding will support
them and convey unspecified meaning to resolvers.

i'm more interested in the fact that this compromise is between two invalid
positions.  size arguments have been shown invalid by ted@nlnet, whereas
paternalistic arguments have been shown invalid by me.

rather than compromise between two invalid positions using an encoding
which is undetectably violatable, i think we ought to reverse the sense
of the poll.  opt-in has been proposed.  can anyone oppose it on grounds
which are (a) technical and (b) not yet shown to be invalid?

if not then i urge the chairs to put markk's latest draft out for last call.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jan 2002 23:23:47 -0800

to cause the break in tradition to be symmetric, "i agree with randy."

> the information seems not too useful.

this is what i meant by "unenforceable" and "undetectably unspecified".

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 15 Jan 2002 02:39:39 -0500

>the information seems not too useful.

(I'm not glossing over any details this time so bear with me :-)).

Resolver must be able to determine, current DS draft (05) requires that any 
time
NS is in answer or authority section that DS and NXT for that name be added to
the authority section, this does not cover the some of the cases that Opt-in
creates  (see below).

Assumption #1:
(Paranoid) resolver will attempt to determine the security status of the zone.

Opt-in document allows the setting and omitting the NXT bit on any name,
if NXT bit is set then there is no insecure name in between the
name on the left hand side and the name on the right hand side.
For secure zones the resolver will know by looking into the NXT what is
the state of the name it is examining. There are 4 different cases:

                              left hand name
                     matches              differs
NXT bit set       secure node        name does not exist
NXT bit clear     secure node        unsecured name may exist.

This is unchanged by my text.
What the my suggested text changes in Opt-in spec is:
1. Only Delegations are can be covered/omitted by opt-in.
2. Existence of some unsecured delegations can be authenticated.

Opt-in (+DS) zones now have three different types of delegations
fully secured      "NS SIG [NXT] DS" and left hand name matches query
provably exists    "NS SIG [NXT]"    and left hand name matches query
not covered        NXT names span the query name and does not have the NXT 
bit set.

If my proposal is accepted, Opt-in will have only one kind of non delegation
nodes: Secure.

Current Opt-in draft assumes that names are either fully secure or not covered,
the middle case is quire possible and might in the long run be more popular 
than
fully secure.

If DS dies, Opt-in needs to add text to require NXT to be handed out
when available at delegation.
If Opt-In passes in any form either DS or Opt-in Document needs to explicitly
specify the NXT processing at "not covered" nodes.
Finding the covering NXT might be quite expensive thus some care should go 
into this
decision and there are significant tradeoffs here.

Contrary to what most people think, NXT is the most expensive part of DNSSEC
implementations due to the following: (this is not a complete list)
         Finding covering NXT dictates ordered data base.
         NXT generation requires whole zone to be available
         NXT maintenance forces on-line keys for zones allowing dynamic 
update.
         There are two different NXT sets at delegations (same name) that 
must be
                 kept apart and both must be available.
         Chasing parent NXT (and NULL KEY) is frequently required but not 
always possible.
         NXT verification is needed on all negative answers.

Doing crypto is easy compared to all this.

         Olafur

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Jan 2002 04:13:22 -0800

> if not then i urge the chairs to put markk's latest draft out for last

we did.  the call ended 2002.01.07, a week ago.  there was no consensus.
we're trying not to close the door, but rather encourage discussion to
try and find if there is a reasonable, high-quality, position over which
we can reach consensus.  sad to say, none has yet emerged.

randy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jan 2002 11:08:50 -0500

>we can reach consensus.  sad to say, none has yet emerged.

I really hate impasses, such as this one, which really have little
technical basis.  The problem is that at some point some group will have to
decide one way or another.  In this case, no decision is essentially a
"don't do it."  This is unfortunate because the IETF is all about open
consensus, but when it comes to a yes/no question that isn't solved by a
technical acheivement, something has to give.

My largest concern is that, given there will be a "winning" and a "losing"
side barring a compromise, is that the "losers" will feel slighted.  I hope
that isn't the case for long.  (Although this message is a bit whiney about
the situation, I am not disappointed in the activities.  I think the thread
has been pretty well behaved so far.)

My personal bias is for OPT-IN. I have my two reasons - the reasons have
been all over the mail list from other's fingers so I won't repeat them
here.  One of my reasons can be worked around.  The other isn't a technical
one, so there's no sense arguing it.

When I think about this debate, OPT-IN isn't really that crucial an issue.
It's  become something to argue about.  Let's not let the act of arguing
delay the other work.  I'm sure that whatever is decided will be forgotten
in five years.

PS - The one dilemma that I keep running into is the "I hate Verisign
because they are this economic monolopy capable of strangling the net"
versus "Versign has the most cummulative experience in operating DNS
servers and registries."  I hope that folks who really believe one of these
two stop to consider the other side of the coin.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 15 Jan 2002 11:37:03 -0500 (EST)

Hey, I have a completely off-topic question: why are SIG records so big?
People were saying that they're about 128 bytes.  Couldn't we hash them
down to 128-256 bits (16-32 bytes) plus a little overhead?  It may be a
little late in the game for such a change, though.  Just curious.

> them and convey unspecified meaning to resolvers.

I can't really tell what you mean.  Under the compromise, a resolver
should refuse to accept unsigned authoritative data in a signed zone, just
like should refuse to do so now.  The only new thing a resolver should be
willing to accept is an unsigned insecure delegation at a zone which
indicates it's using opt-in.

That seems enforceable to me, and very much specified.

> paternalistic arguments have been shown invalid by me.

Writing a message opposing a position does not constitute "showing the
position invalid."  Ted's argument boiled down to "I can't imagine anyone
saying that a 4-fold to 6-fold initial size increase in the .com zone is
unacceptable," and your position on paternalism, while valid, is not
shared by everyone in the group.

Essentially: Verisign says they can't deploy DNSSEC with such a large
initial increase in cost.  (And I know of no incentive for them to make
that argument dishonestly, since they can already charge extra for KEY
records as things stand.)  The group can't get consensus on supporting
fine-grained security of authoritative data.  We have a compromise which
should make both sets of people happy.  Is there any reason, other than
pigheaded obstructionism, why we're not just taking the compromise and
running with it?

(Yes, there is a reason: opt-in raises complexity a little, and only helps
a small number of zones.  But they are very large zones which get used a
lot, and it's not a great deal of complexity, so that's not a compelling
argument.)

> which are (a) technical and (b) not yet shown to be invalid?

People oppose it because they see it as likely that only a small amount of
DNS will be protected if we support fine-grained protection.  You may not
agree with that position, but you haven't "shown it to be invalid" to the
extent of getting consensus.

---

From: David Blacka <[email-masked]>
Date: Tue, 15 Jan 2002 13:40:20 -0500

>>>>> "ogud" == Olafur Gudmundsson <[email-masked]> writes:

 ogud> <chair hat off>

>From the perspective of VeriSign, this compromise is perfectly fine.

However, from my own perspective, I either do not understand or
possibly just don't agree with the arguments that have led to this.

 ogud> The argument that I want to make is about the maintainance of
 ogud> zone with some names secured and some insecure, has the
 ogud> potential to be an administrative nightmare, as there must be
 ogud> an indicator for each name (or sequence of names) that
 ogud> indicates when to sign and generate NXT.

This seems to me to entirely be a tools issue.  For sure, a zone
signer could be implemented that makes opt-in hard.  But there are
zillions of ways to implement a zone signer interface, and many of
them won't create administrative nightmares.

Olaf writes:

  I always thought that DNSSEC was designed to secure the DNS system
  as a whole. I would say that is something as a 'public good'. 

And others have written that the goal of DNSSEC was to "protect the
DNS infrastructure", which I'm guessing means the same thing.

I can sort of understand this as a noble goal.  But, since 2535 allows
for insecure zones, I have a hard time seeing this actually happen
with or without Opt-In.  Unless we have a flag day at some point and
*force* people to secure their zones, it seems to me that there will
always be insecure zones.  Changing the granularity doesn't seem to
change the situation at all.

A general fear seems to be that opt-in will lead to dramatically less
of the whole DNS being secured.  I'm not really convinced that this is
the case, but even so, why does this have to be enforced by the
*protocol*?  The draft already states that opt-in should only be used
where necessary, and I should hope that the tool writers will
communicate this by never making opt-in the default.  I guess I don't
see why the language in the security implications section of the draft
isn't enough to prevent the majority of folks from using it.

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

---

From: Mark Kosters <[email-masked]>
Date: Tue, 15 Jan 2002 13:18:41 -0500

> pigheaded obstructionism, why we're not just taking the compromise and

In the teleconf we had before Christmas, the objections made to restricting
opt-in only to delegation points that I remember were:

1) code complexity to enforce this (an alternative is restricting by 
   policy and common convention).
2) those who wish to hide non-secure rr sets from nxt walking.
3) benefits only large zone maintainers.

But, if restricting opt-in to delegation points reduces the fear in those 
who are opposed to opt-in, the authors have no problems in placing text
to that effect in the next version.
 
> lot, and it's not a great deal of complexity, so that's not a compelling

Agreed.

> extent of getting consensus.

I don't follow some of this "closed-case" reasoning either. I think trying
to force people to secure all their zones data by placing restrictions in the 
protocol is misguided. One needs to do this by showing the usefulness of
securing their rr sets within dnssec. I personally believe they should 
have a choice on what they want to do with their own data.

But again, if adding text that restricts opt-in only to delegation points
gains more acceptance, the authors are fine with this.

Mark

-- 

Mark Kosters             [email-masked]       Verisign Applied Research

---

From: Derek Atkins <[email-masked]>
Date: 15 Jan 2002 17:06:59 -0500

> them and convey unspecified meaning to resolvers.

Except it wouldn't be unspecified to a compliant resolver.  If a
resolver sees a response that looks like:

        foo.example.com. in a 10.0.0.1
        example.example.com. in nxt good.example.com. ...
        example.example.com. in sig nxt ...

where the nxt has no-opt set (i.e. nxt bit clear), then a compliant
resolver would know that foo was a forged response (because you're not
allowed to put authoritative data in an opt-in area).

In other words, the nxt shown above says "the only information that
can exist between example.example.com. and good.example.com. are
non-authoritative data (NS records and non-authoritative glue A
records).  Anything else that appears is deemed by the resolver to be
garbage, because it's not allowed.

This is 100% specified to a compliant resolver.  Obviously if an
implementator makes a non-compliant resolver then all bets are off,
but we're already talking about resolvers that comply with the spec,
right?

So, where is the confusion?

-derek

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jan 2002 14:20:26 -0800

> ...
> ...

in my head.  thanks for clearing it up.  i withdraw my objection to
olafur's restated version of this "only delegations can opt out" proposal.

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Jan 2002 14:49:25 +0700

Date:        Tue, 15 Jan 2002 11:08:50 -0500
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <v0313031cb86a018dc13a@[192.94.214.123]>

  | I really hate impasses, such as this one, which really have little
  | technical basis.

I generally stay out of dnssec (what used to be dnssec) arguments, as I
don't have the true security background to avoid making a fool of myself.

But from what I have been able to conclude from reading all of this, there
are no technical arguments here at all.   The whole argument is gibberish
(on both sides).

The calculations of extra load (done by both sides) are utter nonsense - not
necessarily so much because the numbers are wrong (though I actually believe
that both sides are fudging), but because truly the whole question is
irrelevant.   Running a registry is running an infrastructure business, and
infrastructure, by its very nature, tends to require the occasional large up
front investment, which is then recouped over the operating lifetime.
DNS registries (as opposed to registrars, who are just resellers, and hence
a service industry) should be expecting to have to make capital investments,
and then make profits from them later.

What's more, I can't believe for a second that Verisign doesn't understand
that perfectly well - obviously they'd prefer not to have to spend if it can
be avoided, but that cannot rationally be any kind of genuine argument.

More than that, if dnssec deployment happens anything like the way other
internet technologies have been deployed, and I can't imagine why it wouldn't,
there will be (after availability, whenever that is) a period of almost
zero use, followed by a sudden upsurge of demand, which I'd guess might
take .COM from about 2-3% secure to 40-50% secure in a 6-8 month timeframe
(the issue will hit the popular/trade press somewhere, and all the lemmimg
managers will suddenly decide they they also need this, right now).
Versign have to be expecting something like that, and planning for it,
which means developing the means to handle the zone file when it is
almost completely signed, which I think everyone agrees means about the
same load, with or without OPT-IN.  To do otherwise would be foolish.

On the other hand, the arguments against OPT-IN seem to be missing completely.

I understand this "change the nature of dnssec" stuff - but we have no dnssec
at the minute, it is just a dream, and changing the nature of a dream doesn't
seem to me to be something that needs to be avoided at all costs - especially
when the change seems to be so comparatively trival.

I'd suggest that we should do as Paul Vixie suggested a couple of days ago,
and return to first principles.  Assume that the whole thing was just
being designed now, except with us having all the knowledge that we actually
have about how all of this works, and what it costs.

If the result of that would be that OPT-IN, as he asserted, then that is
what should be done.

Just everyone please stop repeating the previous set of non-arguments, both
ways, over and over again.

kre