Subject: Transition from 2535 to opt-in

From: Olaf Kolkman <[email-masked]>
Date: Wed, 28 Nov 2001 14:42:20 +0100

Hi Roy, Mark & David

I think that the transition issues need some attention in
draft-ietf-dnsext-dnssec-opt-in.

I am afraid that an RFC2535 verifiers (not opt-in aware) will not be
able to see the non secured part of an opt-in zone.

An example of that:

Assume my RFC 2535 verifier is configured to use "example." as a root
of security (Trusted-key in named.conf speak) or more general the zone
is marked secure by it's parent.

If I do a query for QNAME=unsigned.example QTYPE=mx I will get an answer
as in your's example A.1:

         RCODE=NOERROR

         Answer Section:
         UNSECURE.EXAMPLE.      MX    ...

         Authority Section:
         SECOND-SECURE.EXAMPLE. NXT   EXAMPLE. NS SIG KEY
         SECOND-SECURE.EXAMPLE. SIG   NXT ...

         Additional Section:
         EXAMPLE.               KEY   ...
         EXAMPLE.               SIG   KEY ...

Since there is no SIG on unsecure.example I must mark this RR as BAD
and discard it. Hence all unsecured records are not visible to an
RFC2535 verifier.

As for possible transition scenarios I am afraid that there is no
smooth transition possible; it seems to be a 'flag-date' thing. 

--Olaf

---------------------------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC DISI Project     
     -----------       |      ---------------	     ----------------
  RIPE NCC             |  Phone:   +31 20 535 4444   | 
  Singel 258           |  Fax:     +31 20 535 4445   | 
  1016 AB Amsterdam    |  http://www.ripe.net/disi   | 
  The Netherlands      |  [email-masked]          | 

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

---

From: Brian Wellington <[email-masked]>
Date: Thu, 29 Nov 2001 15:51:48 -0800 (PST)

> smooth transition possible; it seems to be a 'flag-date' thing. 

I don't think that this is a problem.  If a TLD is opt-in and a resolver
is not opt-in capable, it shouldn't contain a trusted-key for that TLD.

Trusted keys (in BIND, at least) need to be explicitly configured, and 
there's no reason to configure a trusted key for an opt-in zone if the 
resolver doesn't support opt-in.

Brian

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 30 Nov 2001 08:50:36 +0100

* I don't think that this is a problem.  If a TLD is opt-in and a resolver
 * is not opt-in capable, it shouldn't contain a trusted-key for that TLD.

How does that work if you enter the zone from a parent? I see that as
long as the root is not signed this is not a problem for a TLD but in
a general case a zone that is supposed to be secure and that uses
opt-in will only have it's secured RRs visible.

For the generic case 2535 verifiers will have a problem with OPT-IN.

--Olaf

---

From: Roy Arends <[email-masked]>
Date: Fri, 30 Nov 2001 10:54:54 +0100 (CET)

> For the generic case 2535 verifiers will have a problem with OPT-IN.

You are right when it comes to an opt-in zone, indicated secure by its
parent. 2535 verifiers will have a problem with unsigned data in an opt-in
zone, and they should ! The verifiers don't have a problem with signed
data in an opt-in zone, as it is, eh, 2535-compatible(tm).

In general, non-upgraded verifiers lack new functions. In this case, I
don't see it any different then for example a verifier which can not
handle DS.

You've made a good point though, this is not clearly mentioned in the
draft. We could put in a "transition" section.

Thanks and regards,

Roy

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 30 Nov 2001 09:35:25 -0500

>resolver doesn't support opt-in.

What if resolver is configured with key for  "." which follows RFC2535.
"." signs ".example" key, and ".example" is using Opt-in.

Will a RFC2535 compliant resolver discard "unsigned.example."  as bogus ?

If the answer is yes, then we MAY be forced to put in policies like
"RFC2535 zone can not sign KEY for Opt-in zones".
Forcing all Opt-in zones keys to be configured, preferably tagged
as opt-in keys.
As the number of opt-in zones, hopefully, will be small and all of them
highly visible.
If only the REAL LARGE delegating zones use Opt-in, this might be
tolerable pain.

         Olafur

         Olafur

---

From: Brian Wellington <[email-masked]>
Date: Fri, 30 Nov 2001 09:53:18 -0800 (PST)

> Will a RFC2535 compliant resolver discard "unsigned.example."  as bogus ?

Yes.

> "RFC2535 zone can not sign KEY for Opt-in zones".

I don't think this is a good idea.  Then if .com was opt-in (which it
should be, since .com is the whole reason for opt-in), the root could not
be RFC 2535 signed.

There's also the problem that with the newest opt-in draft, there's really
no concept of the entire zone being opt-in or RFC 2535, but a distinction
per NXT.

> Forcing all Opt-in zones keys to be configured, preferably tagged

This was in an earlier version of opt-in.  I don't fully understand why it
went away, but also don't think it would help.  If an RFC 2535 capabale
resolver wasn't updated to support opt-in, it likely also wouldn't
understand that a key indicated opt-in.

> If only the REAL LARGE delegating zones use Opt-in, this might be

Exactly.  Realistically, the only zones that will use opt-in should be the
big gTLDs, and maybe a few ccTLDs.  Even if the root is signed, it doesn't
make sense for anyone with a non-opt-in capable resolver to add the root's
trusted key to their server's configuration.

Brian

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 30 Nov 2001 12:05:07 -0800

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

experience so far shows that if we sign up for another round of complexity on
the scale of opt-in we'll be some years at fine tuning it before we can have
meaningful interoperability testing on it, which would precede wide deployment
by some more years.

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.

re:

> To: Brian Wellington <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked],
>    [email-masked]
> Subject: Re: Transition from 2535 to opt-in 
> Date: Fri, 30 Nov 2001 08:50:36 +0100
> From: Olaf Kolkman <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
>