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: "Loomis, Rip" <[email-masked]>
Date: Tue, 22 Jun 2004 04:42:26 -0400

Hi Ed--
Trying to reply only to one part of a much more significant
message:

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

Re-using key material will not inherently be a "crypto-problem"--
given that the plaintext to be signed will be slightly different,
the problem is that the crypto "lifetime" of the key will decrease
at something approximating half the "lifetime" (effectivity period)
that would otherwise be expected [0]--all of a sudden one is signing
(basically) twice as much data so by certain attacks the key would
be expected to be attackable in ~half the time.  However, that
would be expected to be a surmountable problem.

I agree with you that if -bis and -ter are both actively used in
the field simultaneously (which I would expect) then for a maximally
compliant system I would prefer to use the same keying material
for signed DNS in both systems.  I think it's a realistic goal,
although I invite comments in case I missed the bus on something...

  --Rip

[0] Based on all I know of currently published cryptanalysis attacks
on the algorithms in question.  If someone's got more data, please
provide it.  Yes, there may be some interesting differential
cryptanalysis attacks possible based on the fact that the two sets
of plaintext will be _real_real_ similar with only very slight
differences--but for now I'm throwing those out because I don't
think they will be significantly more productive than the "joe
average" attacks against a known plaintext for these algorithms.

---

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

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: David Blacka <[email-masked]>
Date: Wed, 23 Jun 2004 12:52:15 -0400

On Tuesday 22 June 2004 8:21 pm, Paul Vixie wrote:
> > From: David Blacka <[email-masked]>
> >
> > 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.
>
> depends on what you mean by "publish".  my current -ter draft suggests
> 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.

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

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.

> > Wouldn't transition just be *easier* if a zone signed using -bis could
> > 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.)

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

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

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.

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

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?