Subject: Re: Transition from 2535 to opt-in

From: "David R. Conrad" <[email-masked]>
Date: Sun, 02 Dec 2001 18:33:09 -0800

Paul,

At 12:05 PM 11/30/2001 -0800, Paul A Vixie wrote:
>i keep looking at opt-in and DS and asking "how many more years will it take
>before we get the complexity managed in dnssec and have widely deployed it?"

Yes.

>i have an alternative proposal.  use hardware crypto and since .COM with the
>protocol we have now and stop the merry-go-round of dnssec protocol 
>development
>before a lot of us are overcome with motion sickness.

While I too would like the merry-go-round to stop, signing large zones like 
.COM isn't the problem, or rather it is among the easier problems to solve 
-- just throw hardware at it as you note.  The harder problem to solve is 
propagating O(10 GB) worth of DNS data globally in a short amount of time 
(particularly in the worst case scenario of private key compromise).  The 
next hardest problem to solve is key management, particularly in the same 
worst case scenario.  The hardest problem to solve is to convince people 
DNSSEC does something useful -- it appears there is a view that protecting 
name/address translations aren't particularly interesting given there are 
other ways of skinning that particular security cat that are already in use 
(e.g., SSL, TLS, etc).  Of course, the DNS can be used for things other 
than name/address translations and insuring the integrity of that data 
would probably be important, however there are people who believe that such 
use of the DNS is ill-advised.  Fix the last problem and I'm sure DNSSEC 
will be deployed, regardless of what the IETF thinks needs to be done wrt 
the standards.

Rgds,
-drc

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

---

From: [email-masked] (Ted Lindgreen)
Date: Fri, 7 Dec 2001 16:57:23 +0100

[Quoting Roy Arends, on Dec  7, 11:30, in "Re: Transition from  ..."]
> On Thu, 6 Dec 2001, Ted Lindgreen wrote:
> 
> > then I argue that authenticated denial is not needed, as we now
> > only need to prove that a certain RR that we want to be secured
> > verifies. Example:
> >
> >  I (secure aware user) want to setup an ssh/ipsec tunnel, do
> >  banking business, or whatever, with you (secure aware site).
> >  It would be very handy, if I can get the key-info from DNS,
> >  but I would only use that info when it verifies.
> >  The same is true for the other side, as you want to make sure
> >  that I am the one I pretend to be.
> >  Now there are only two possibilities that matter:
> >  1. It verifies ==> OK
> >  2. It does not verify ==> not OK, but further it is totally
> >     irrelevant whether the info was bad, spoofed, had an
> >     outdated sig, or was intentionally not secured: for its
> >     usage it is just not good enough.
> 
> 
> 
> ridiculous
> 
> 
> 1. it verifies ==> OK
> 2. it does not verify ==> not OK.
> 
> Then I want to know what went wrong.
> 
>  -) Spoofed ?
>  -) DoSed ?
>  -) Simple typo on my side ?
>  -) some other unexpected variable ?
> 
>        OR
> 
>  -) is it VERIFIABLY UNSECURE ?
> 
> The difference between the first 4 points and the last is authenticated
> denial. With the first 4 you simply don't know what went wrong.

Yes, that is exactly the point:

- When "you" are the DNS infrastructure, this info is essential, because
  it distiguishes your actions between:
  - It is BAD ==> Throw it away.
  - It is intentionally not secured ==> Keep it as such.

- But when "you" are a user, interested to use valid key-info, then it is
  only usable when it verifies.
  If it does not verify, the next step is error handling, in which the
  DNS-protocol may or may not assist you in analysing the problem.
  And perhaps you even have to call/mail some relevant person
  to ask "what's up?".
  But in the meantime the bottomline remains:
    no verification ==> no valid key-info.
 
> When you identify your bank and it is not ok, you then simply go home and
> tell yourself "not ok" and don't care about it ? The rest is irrelevant ?

 When this bank tells me my credit card is "not ok", I certainly do care
 about that, and it is certainly relevant. I have to go into an error
 handling procedure, in which the bankemployee or ATM machine may or
 may not assist me in analysing my problem. Perhaps I even have to call
 my own bank to ask "what's up?".
 But in the meantime the bottomline remains:
    no valid credit card ==> no money.

Please note, that there is a difference between:
 "securing the infrastructure", where you want to weed out all the BADs
 between many certifieds and uncertifieds;
and
 "securing certain special RRs, such as an ipsec-key", where you just
 want to check that your special RRs verify and all other RRs are
 irrelevant.

The difference is that in the former authenticated denial is crucial, and
in the latter at most informative for error handling.

Regards,
-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Dec 2001 11:33:14 -0800

Paul,

	Your argument reminds me of the Menendez brothers, who shot their
parents and then asked the court for liniency because they are orphans. If
you want the discussion to stop then don't fillibuster.

	Deployment issues are NEVER solved by ignoring them. If you succeed
in your apparent aim of stopping deployment of Opt-in you will stop
deployment of DNSSEC entirely in the large TLDs. Furthermore, if you were
correct in your assertion that Opt-in is incompatible with 2535 then partial
deployment in the small domains would block any deployment in the large
domains until a new opt-in spec is developed. I dispute your initial
assertion but if you insist on making it then please note that in the
absence of deployment the discovery of an error in a protocol that prevents
extensibility argues for fixing the protocol and not propogating a broken
one.

	Let us consider the history of some other IETF working groups. PEM
did not advance deployment by refusing to change its undeployable PKI
architecture. The intransigence of the PEM working group eventually
fractured the email security space so that we had PGP and S/MIME in
competition.

	This is an engineering issue. Without opt-in the DNSSEC records for
.com will take up approximately ten times their current amount of space.
That means ten times the amount of RAM, ten times the amount of disk
storage, ten time the amount of silo storage etc. The costs of signing the
zone are prohibitive even before we count the cost of the signing devices or
work out how to securely manage the necessary number of private keys.

	This is before you get to the problem of distributing the data. If I
was on the ICANN board I would explicitly prohibit my contractor from
deploying DNSSEC without opt-in. The risk of introducing instability into
the main TLDs vastly outweighs any advantage that can be argued for DNSSEC
prior to deployment.

	I am an engineer. For me the cost of deployment is a significant
issue. If a specification requires large deployment costs for a security
feature that few parties will be able to take advantage of then it is a bad
specification.

	As for your analysis of the security requirements; first DNSSEC will
provide no security at all if it remains as spec-ware. Second I do not agree
that you have identified a significant security issue.

	If it were the case that I had $O(10^8) extra to spend on DNS
security I would be spending it on physical security (and I would not be
telling you in particular what I was doing). Cryptography is no defense
against terrorists whose principal skills are knowing how to clean an AK47
and milk a goat. I don't have great respect for people who go around
announcing possible targets to these folk through the AP and Reuters.
Careless talk such as yours could cost lives. Perhaps next time you could
give the street addresses of the new facilities as well so they don't bomb
an empty building by mistake.

	It is very easy to delay deployment of cryptographic specifications
by raising alleged security issues that can only be addressed at prohibitive
cost. If you wish to continue your filibuster please do not blame others for
the delay in deployment that you are causing.

	At this point there are only two possible outcomes:

1) We deploy DNSSEC with opt-in.
2) We design a new specification entirely.

	If you insist that you cannot live with option 1 and the group
agrees with you then it is time to burn the 2535 drafts and start again. The
sooner we do this the better, since the longer we delay starting the longer
it will be until we finish.

	I would prefer to begin by deploying DNSSEC-opt-in and then start
consideration of additional opportunities there are to add security to the
DNS system.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Research
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Paul A Vixie [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 3:35 PM
> To: [email-masked]
> Subject: Re: Transition from 2535 to opt-in 
> 
> 
> > Expensive in that this mechanism can only be done once.  If 
> we use the NXT
> > bit in the bitmap for this purpose, it can't be done again.
> 
> sure it can.  we can continue discussing the whichness of 
> what in our ivory
> tower for another five years (it's already been five years; 
> what's five more?)
> three years from now we'll have opt-maybe, opt-in, opt-out, 
> and who knows what
> else.
> 
>