Subject: concerns with TCR as a transition mechanism

From: David Blacka <[email-masked]>
Date: Mon, 21 Jun 2004 15:36:09 -0400

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.

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.

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.

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.

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?

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

--
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: Edward Lewis <[email-masked]>
Date: Mon, 21 Jun 2004 17:02:04 -0400

[off-list]  'cuz I don't have answer to your question...

I really agree with your points, and I'm glad you are asking the 
question.  It kinda goes along with the thought I threw out that 
maybe we ought not encourage the dissemination of a trusted key until 
whatever hits Draft Standard.  Maybe not explicitly, but I meant what 
I think you mean here.

If you get my drift...

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Jun 2004 20:19:30 -0400

Sorry for missposting.  I was trying to be off-list because I really 
didn't have time to say more intelligent than "me too."

But since I did...I too am concerned about TCR not providing 
backwards compatibility.  But I don't think that it's a problem 
unique to TCR.  Any transition method that tries to provide backwards 
compatibility will imply code size creep - DNSSECtis code bases would 
need to have DNSSECbis abilities (whether or not used) if we don't 
want to "hang" DNSSECbis adoption efforts.

Hence my "drift" about being tempted to not issue trusted keys until 
Draft Standard.  I don't want to encourage that, but, what's the 
choice between more code, a flag day, delay?  That's something I just 
don't have time to give thought to now.

At 17:02 -0400 6/21/04, Edward Lewis wrote:
>maybe we ought not encourage the dissemination of a trusted key 
>until whatever hits Draft Standard.  Maybe not explicitly, but I 
>meant what I think you mean here.
>
>If you get my drift...
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jun 2004 01:07:35 +0000

> 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."  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, 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:

   2.5. A zone signer and/or authority server might choose to support both
   DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER.  It
   is expected that a validating recursive server, or a caching recursive
   server, will support either DNSSEC-BIS alone (as is the case today), or
   both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone.

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

(ed, your concerns about codesize creep should have come in immediate
response to -ter draft, since section 2.5 quoted above makes it clear that
now that i've got more RAM in my digital camera than was present in the
whole state of california at the time i used my first timeshared computer,
i don't consider codesize creep to be an important issue.)

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

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

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

---

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

---

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

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

> that the "-ter transition" would flow from the trust anchor(s) "downward".

Not the most flexible assumption, IMHO.

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

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

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 00:24:07 +0000

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

that's a different issue.  for -bis, we decided not to roll the request
bit and just roll the response rrtypes.  for -ter, i'm expecting that we
will have to roll both.  in <draft-vixie-dnssec-ter-01.txt> section 2.3,
i propose a specific method by which hop-by-hop request signalling is
"promoted" to end-to-end.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 00:21:08 +0000

> From: David Blacka <[email-masked]>
> 

depends on what you mean by "publish".  my current -ter draft suggests
that new/different EDNS signalling will solicit -ter metadata, which if
available would supercede the return of -bis metadata.  (see section 2.1.)

so, any zone owner who wanted to continue to serve the -bis validator
community could (and probably would) "publish" both kinds of metadata
during the transition period, which is likely to be five to ten years in
duration.

whether they use the same key data or different key data depends local
policy.  (DNSKEY may or may not be one of the types that has to be
rolled, but even without rolling it, it's possible to publish more than
one key at a name and use them for different purposes.)

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

during the recent discussion of protocol fields i got a little lost in the
details.  but since we don't have to decide which type codes will roll (or
indeed if any of them will roll) in order to decide that -bis can be made
into -ter at some later date, i disagree that the discussion is in-scope.
i do agree in principle that a partial TCR would be less eventful than a
full TCR, and that it may turn out to be possible to keep the existing
in-tree DNSKEY data and/or DNSKEY RR format, and that if we can do this it
would be preferrable to a full TCR.  but none of that matters right now.

what's "in-scope" at the moment is whether -bis constrains -ter so strongly
that we had better not let it go to iesg after all.  for that purpose, it's
only nec'y that we describe a workable "most expensive case" and then decide
whether it's too expensive or won't work.  if a workable "most expensive case"
is something we're willing to sign off on as a working group, then we still
have total freedom to invent something less expensive for "actual -ter."

> > ... so, my basic assumption has been that the "-ter transition"
> > would flow from the trust anchor(s) "downward".
> 

i'm just painting a bookend for the shelf.  you don't have to love it, and
you don't have to agree that we're forced to do it that way.  you just have
to decide whether you could live with it if nothing better is invented, in
case nothing better is in fact ever invented.

> > ... delegation-only or delegation-mostly (collectively "non-leaf")
> > 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?

i think i answered exactly your point, but apparently i missed, so i'll
try again.  the non-leaf zone operator could be in the exact same position
at the beginning of -ter deployment as they are today at the beginning of
-bis deployment -- and that is, they're waiting for a useful trust anchor
and a useful path from that trust anchor to their own keys.

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

today, neither.  for all we know, -ter will not require DS RRs or anything
like DS RRs, and trust anchors will be connected to zone keys by some method
other than delegation paths.  see the abstract, and sections 1.1, 1.2, and
1.3 of <draft-vixie-dnssec-ter-01.txt>.

> securely delegate to a zone signed with -ter?

yes, of course it would.  and if we can find a way to attach those rocket
boosters to this pig, then it will fly just like you're saying.  but that's
for the -ter designers to work out (which may or may not include you and i.)

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

it sounds as if yours is a lot more specific than mine.  i don't have one!
all i know is, the worst case will work, and at a price i expect both the
-bis installed base (if any) and the zonewalk-averse crowd would be willing
and able to pay.  i hope that something a lot better than TCR will be
invented but that's not the topic i'm addressing today because it doesn't
affect this working group's decision as to whether or not to forward these
documents to iesg or not.

> comfortable using EDNS0 signalling?

as a worst case?  yes.  i could live with it.  but i'm not sure that the
designers of -ter (who may or may not include you and i) will not invent
something better.

so, i'll ask my question in a more straightforward manner, too.  are we
comfortable with the current -ter draft as a worst case, and does the 
current -trans draft adequately describe the pitfalls available to us?

---

From: David Blacka <[email-masked]>
Date: Wed, 23 Jun 2004 12:52:15 -0400

On Tuesday 22 June 2004 8:21 pm, Paul Vixie wrote:
> > 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.
>
> that new/different EDNS signaling will solicit -ter metadata, which if
> available would supersede the return of -bis metadata.  (see section 2.1.)

By "publish" I mean: make available on the Internet.  Which I think is
a fairly normal usage of the term.

My logic for my statement above goes something like this:

  * DNSSECter exists because DNSSECbis is unacceptable for some zone
    owners.
  * If I am one of those zone owners, publishing -bis metadata defeats
    the purpose of creating DNSSECter.
  * If I am not one of those zone owners, why should I publish -ter
    metadata?

What I was forgetting, I think, was that zone owners who make
available both -bis and -ter metadata are motivated to do so because
1) they can live with (or are quite happy with) -bis, but their
children need -ter.

So, under your proposal, some (most?) parent zones would (essentially)
sign their zones twice, with -bis and -ter, to allow for a clear trust
path for their -ter-only children.  I do not mean this as a criticism.

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

What I am trying to get at is the concept that we might want explore
and describe other, non-worse-case transition plans.  The reason why I
feel that this discussion is in scope is that some of these other
plans might require some language changes to DNSSECbis.

I guess I'm disagreeing with the concept that because we've discovered
*one* way to move from -bis to -ter, the conversation must then be
over.  I will agree, certainly, that we shouldn't spend an indefinite
amount of time exploring other transition plans, but we shouldn't
dismiss the possibility out of hand, either.

When I attempt to get you (Paul) to comment in more detail as to why
using the DNSKEY protocol field does not have merit, what I am trying
to do is to get you to convince me to stop wasting my time on it.

> for the -ter designers to work out (which may or may not include you and

You imply that this behavior would be difficult to achieve.  In my
mind it is not.  Or more precisely, it *may* not be difficult.

> > and you can tell me why I'm wrong.

I think I misspoke a little, here.  What I was really trying to
describe is the model of how DNSSECter (which is unknown) interacts
with DNSSECbis, not what DNSSECter is or is not.  And we all have some
sort of model for that.

> documents to iesg or not.

If we can propose a "better way", but it requires some minor language
changes to DNSSECbis, then wouldn't that affect the decision to
forward?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 19:52:58 +0000

> 1) they can live with (or are quite happy with) -bis, but their

yes, i think so.

> > during the recent discussion of protocol fields i got a little lost
> > in the details.  but since we don't have to decide which type codes
> > will roll (or indeed if any of them will roll) in order to decide
> > that -bis can be made into -ter at some later date, i disagree that
> > the discussion is in-scope.
> 

i think we have to presume that there aren't until we come up with one.

> dismiss the possibility out of hand, either.

i understand.

> to do is to get you to convince me to stop wasting my time on it.

it might not be a waste of time.  but i don't think we're going to be able
to propose relaxations or tightenings of the -bis spec based on non-concrete
designs, and i don't think we have enough time in the current -bis window
to come up with a "concrete enough" design.

even apparently-simple relaxation proposals like "make NSEC optional" end
up touching a hundred small other parts of the design.  the model is self-
consistent at the moment and there's almost no such thing as a small change.
(one of us also noted recently that "we have 11 years of history showing that
we do not know how to change the dnssec design quickly.")

> changes to DNSSECbis, then wouldn't that affect the decision to forward?

yes.  but the time window is of fixed size, and the problem is not.