Subject: Re: concerns with TCR as a transition mechanism

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

At 15:36 -0400 6/21/04, David Blacka 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.
>
>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/>

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