Subject: Re: concerns with TCR as a transition mechanism

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Jun 2004 22:09:22 -0400

Now that I feel compelled to be involved because I can't keep my 
private mailings private, I'm missing my sitcoms.

At 1:07 +0000 6/22/04, Paul Vixie wrote:
...stuff in reply to David...

I suppose that with tools we can make serving both (all) dialects 
possible - I don't want to have to manage a second set of keys for 
the new dialect.  (Will reusing key material be a crypto-problem?)

Assuming that -ter operators want that because the NSEC is a problem, 
that means that we need to solve the faux-NSEC problem so that a 
-ter-only zone can say there's no DS for -bis verifiers at unsecured 
delegation points.

I suppose that at this point, the question is whether or not the -bis 
docs prevent any "-ter."  It seems they don't, so long as the 
faux-NSEC thing is hammered out.

Whether a specific "-ter" (ever) emerges, then it'll undergo scrutiny.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

--
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: David Blacka <[email-masked]>
Date: Mon, 21 Jun 2004 22:39:42 -0400

On Monday 21 June 2004 9:07 pm, Paul Vixie wrote:
> > It occurs to me that a mechanism for transitioning from DNSSECbis to
> > DNSSECter MUST prevent existing DNSSECbis resolvers from "choking" on
> > newly deployed DNSSECter zones, but it also SHOULD allow DNSSECter
> > zones to secure delegate to DNSSECbis zone, and SHOULD allow DNSSECbis
> > zones to secure delegate DNSSECter zones.
>
> that last part's the killer.  by "-ter zone" and "-bis zone" i'll assume
> that you mean "zones for which only one kind of dnssec metadata is
> available." 

I do not see an advantage for a zone to publish with both sets of metadata.  
In fact, if -ter is attempting to solve the problem we think, there would be 
a great disadvantage to publishing both.

> this is an important point because some here have said that 
> we might do a partial TCR, such as only RRSIG and NSEC, and leave DS and
> DNSKEY as they are but use a different protocol number.  i don't think
> that approach has merit, 

You haven't explained *why* that approach does not have merit.  This topic is 
in scope.

> but the existence of that debate means we have 
> to say very precisely what we mean by "-bis zone" and "-ter" zone.  so,
> by my interpretation of what you meant, you're asking that it become
> possible for a zone to use -bis even though its parent uses -ter -- and
> that's ok by my draft's current language, which is:

Full TCR (with no other signalling) can do this, I think.  I'm not worried 
about this, I'm worried about the reverse.

> the problem creeps in on that third requirement (quoted earlier above) --
> because a zone served by only -bis software will not recognize signalling
> bits for -ter, and probably will not even be able to load zones that
> contain -ter metadata (for example, DS2).  so, my basic assumption has been
> that the "-ter transition" would flow from the trust anchor(s) "downward".

Not the most flexible assumption, IMHO.

> > It also occurs to me that a full type code rollover would probably not
> > be able to do the last part: allow secure delegations from DNSSECbis
> > zones to DNSSECter zones.
>
> right.  just so.
>
> > If this is true, then for a zone to upgrade to DNSSECter, it would
> > have to wait until its parent upgrades, or start its own island of
> > security.  This seems to me that it might have the effect of chilling
> > adoption of DNSSECbis, or chilling the adoption of DNSSECter,
> > depending upon where you stood.
>
> since i've been expecting -ter to be a different protocol than -bis, with
> its own metadata and its own signalling model and perhaps a different
> threat model, i don't see it as chilling at all.  people who need -bis's
> features will deploy it.  based upon their success or failure, and upon the
> quality of -ter when it's proposed, people who need -ter features will
> deploy it. delegation-only or delegation-mostly (collectively "non-leaf")
> zone operators will presumably be as actively necessary to -ter's
> deployment as to -bis's, and they will deploy -ter on the same basis -- if
> their subdomain-holding "customers" ask for it.

You may have missed my point.  How does the "non-leaf" zone operator deploy 
-ter when, say, the root hasn't?  Or when their ccTLD hasn't?  Would you 
force them to start their own island of security, or would you commit to 
getting the root signed with -ter as soon as possible?

Wouldn't transition just be *easier* if a zone signed using -bis could 
securely delegate to a zone signed with -ter?

> > I also note that, although we've done a TCR before (i.e., RFC 3755),
> > the circumstances were different in that we essentially had no
> > installed base of DNSSEC-semel (rfc 2535) to coexist with.  That is,
> > all the TCR had to do was shield legacy resolvers, which it does.
>
> there was a moderate installed based of 2535 resolvers.  there was no trust
> anchor at the root zone, and that's why the previous TCR was light-weight.
> for -ter, we will have to shield new resolvers from old metadata, because
> otherwise even EDNS wouldn't be large enough to hold the response-o-grams
> (since they might end up containing both -bis AND -ter metadata).

Yeah, I don't see this happening.

It is clear that you and I have different mental models for what the world of 
DNSSEC-ter looks like.  Perhaps I will post what my model is, and you can 
tell me why I'm wrong.

> > Paul's partial TCR proposal (which I could be mis-remembering) uses
> > EDNS0 signalling to (presumably) allow all of the MUST and SHOULD
> > behaviors outlined above.  But, I also remember that when we were
> > coming up with the DNSSECbis TCR, EDNS0 signalling was suggested and
> > rejected.  If we were uncomfortable with it then, why wouldn't we be
> > uncomfortable with it now?
>
> again, there was no trust anchor, and the installed base of 2535-style
> authority servers was negligible.  there was no need to shield new
> resolvers from the old metadata, as there presumably will be when -ter
> deploys (since we're hoping that there's a moderate or large -bis installed
> based by then.)

Well, I'll ask the question in a more straightforward manner.  Are we 
comfortable using EDNS0 signalling?

My memory of discussions leading up to 3755 was that we were not, but why not 
always seemed sort of hazy.

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

---

From: Rob Austein <[email-masked]>
Date: Tue, 22 Jun 2004 00:04:43 -0400

At Mon, 21 Jun 2004 22:39:42 -0400, David Blacka wrote:
> ...

I'm less confident in it than I am in TCR (see below).

> always seemed sort of hazy.

Header bit signalling is basicly a hop-by-hop thing, whereas type code
signalling is more of an end to end thing.  As I recall, we concluded
that the original requestor's intent was more likely to survive
passage through a twisty little maze of forwarders, caches, and so
forth via type code signalling than via header bit signalling.  YMMV.