Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a propo sal)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 15 Jan 2002 07:43:30 -0800

> In that decision, I think that security issues should weight a
> little more than conveniance issues.

I agree. But remember that security of a system is very different
from security of a protocol.

It is not a convenience issue if you cannot deploy without a
change. At that point it becomes an operational requirement.

The security of the system is unaffected by OPTIN. Anyone can 
purchase a dotcom domain name with a credit card. The record 
insertion attack is therefore not a risk in that application.

The more complex management of large domains is made, the harder
it is to maintain an acceptable level of security. 

		Phill

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 15 Jan 2002 10:17:27 -0800

> 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.

It is the way that the RSA algorithm works. To verify the
signature you need the 1024 bit signature, a digest is not
sufficient.

It is likely that DSA is optimal in terms of space efficiency
and that does use digests - two of them. the signature is a
validated correspondence between the two 160 bit values.

The problem with DSA is that the signature verification 
process is very expensive. Generation is cheap and so in
schemes like NetBill the client did cheap to verify RSA and
the server did cheap to generate DSA.

If my only concern was the registry side of things then
I might propose DSA (if my QA system did not involve test
verifications :-). However the big problem with DSA is that
the cost of doing DNSSEC rises tenfold on the client (i.e.
secure resolver) side.

> 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?

I have no personal problems with such a proposal. The stakeholders
that might are:

A) The people who write the code.
B) People who might want to deploy OPTIN in applications where
	preventing zone traversal is more important than preventing
	record insertion.

In addition there is a question of the manner of the restriction:

1) A beefed up Security considerations section
	"Do not use OPTIN unless you really really know what you are
	doing".

2) Some MUST or SHOULD condition on generation

3) Some MUST or SHOULD condition on consumption

These sets interact. Coders are unlikely to object to 1 but are
very likely to see difficulties with 3.

If the set B is empty, or if the group does not want to support
them 2 or 3 become options.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 15 Jan 2002 11:38:26 -0800

> [Quoting "Hallam-Baker, Phillip", on Jan 15, 17:16, in "RE: 
> OPT-IN at delega ..."]
> 
> You can try to repeat this indefinitely, but mere repetition
> itself probably does not lead to consensus building.

You can repeat ad-infinitum that you have 'concerns'. However
you have thus far failled to identify any risk that constitutes
a threat under the proposed domain of application that is controlled
in 2535 but not controlled under OPTIN.

		Phill

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 15 Jan 2002 21:10:18 +0100

[Quoting Mike Schiraldi, on Jan 15, 18:56, in "Re: OPT-IN at delega ..."]

> > This is untrue, Opt-In changes the very basis of the system.
> > Whether this is harmless or not is still being debated.
> 
> Could you elaborate on that?

OK, Opt-In changes the definition of the NXT RR from:

  authenticated denial of existance of any name
into
  authenticated denial of existance of a secured name

Sounds basic to me.

> Who is still debating this?

A number of people believe that the granularity influences how
users and ISP's perceive the security, and that in turn will
influence the speed of the roll out.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 17 Jan 2002 08:57:01 -0800

Randy,

	Is the point untrue or otherwise factually incorrect?

	Is the point irrelevant?

	If the argument is advanced that a particular choice will
speed adoption it would seem to me to be very relevant to consider
the real world factors that would shape that outcome.

	The inability to deploy DNSSEC in dotCOM would appear to me
to be a very relevant consideration when considering the likely
outcome. The co-chair may not consider the issue to be significant,
other members of the IESG believe it to be very significant indeed.

	If Ted's original claim was on point then the rebuttal will 
surely be.

	The co-chair can engage in "pissing contests" if he chooses,
that is his choice. I am only interested in the technical issues
here. Needless inefficiency is offensive to my sight, particularly
if I have to pay the resulting costs.

		Phill

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

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 6:05 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: RE: OPT-IN at delegation points only (Re: DS and Opt-in - a
> propo sal)
> 
> 
> > So making it impossible for the operator of 85% of the DNS
> > domain names to deploy DNSSEC will speed up the roll out?
> 
> please stop trying to throw corporate weight.  it will only justify
> pissing contests.
> 
> randy
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 17 Jan 2002 14:34:21 -0800

OK now you have fully explained your objection it sounds to be that we are
returning to the issue that Paul originally identified, the need for a clear
statement of work that describes what DNSSEC is meant to secure and what it
is not.

I don't agree that it is harder to explain OPTIN to that audience. In either
case we have to explain to them that there will be specific authenticity and
integrity guarantees provided to parties querying your domain if you sign
your zone and register your signing key and that other wise there will be no
security. 

It would appear to me that it is much easier to communicate this message if
the OPTIN NXT records only cover the zones that have a signing key
registered. Otherwise what we are doing is like a car manufacturer
installing a lock and alarm system on the driver side doors alone and
claiming that the car is theft proof. We may have removed 50% of the
original vulnerability but we have no more security since the car thief will
simply concentrate his attack on the unsecured passenger side door. A secure
delegation to an insecure server does not achieve much if anything. 

		Phill

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 3:17 PM
> To: [email-masked]
> [Quoting "Hallam-Baker, Phillip", on Jan 17, 18:29, in "RE: 
> OPT-IN at delega ..."]
> ...
> ...
> I thought that Randy's suggestion to throwing the same arguments
> at each other over and over again was very good, and I refrained
> from replying. However, it seems Phillip demands my answer, even
> though all arguments have been repeated many, many, too many,
> times :-(
> 
> OK, but this is really my last post on this subject:
> 
> 1. Yes, Phillip's statement is incorrect: no-one disputes that using
>    non-Opt-In may lead to more startup cost, but also no-one supports
>    Phillip's claim that non-Opt-In makes it IMPOSSIBLE to deploy
>    DNSSEC at large TLDs.
> 
> 2. I am not concerned, that TLDs, both the non-profit TLDs and
>    for-profit TLDs will jump on DNSSEC as soon as:
>    1. The standard has been finalised.
>    2. Serious domainholder demand is expected.
>    Likely, VeriSign will be a frontrunner, Opt-In or non-Opt-In.
> 
> 3. However, I am really concerned, that users (read: the 
> domainholder's
>    clients) may not embrace DNSSEC soon enough that it leads to great
>    domainholder demand. That will lead to only some scattered secured
>    zones and perhaps even only a few RRs. This, in turn will lead to
>    even less users interest, and the process will stop there.
> 
> The reason that I am concerned about the users interest is based on:
> 
> 1. Most of discussion on this list is from a DNS-manager or 
> domainholder
>    perspective. I have hardly read anything from the resolver 
> perspective.
>    I looks like users and their tool, the resolver, are a 
> little ignored.
> 2. At least two software packages to serve domainholders are 
> available, and
>    people are actively improving it.
>    But little is available on the resolver side. BIND-8 has a sig/key
>    checker/chaser ("host -s"), but it's broken. BIND-9 lacks even such
>    a basic tool (NLnet Labs has produced an addition to both 
> "host" and
>    "dig" to implement a checker/chaser in BIND-9. This was offered
>    to Nominum, but not included (yet?)). It looks that there is really
>    little interest in doing anything with the costly KEYs and SIGs...
> 
> I think, that looking at DNSSEC from the resolver perspective needs
> much more attention, and soon, otherwise DNSSEC will likely remain
> limited to scattered parts of the DNS tree.
> 
> Back to Opt-In: from the resolver perspective, Opt-In does not
> seem helpfull to give users a warm, secured feeling, because it
> further obscures what's secured and what's not.
> 
> -- ted