Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jun 2004 22:02:25 +0000

> ... That a user of a cache might have to wait the minimum TTL (or NSEC
> TTL) in order to see a change to a zone is undesirable, ...

Now that we have the ability to sign the SOA, it could be that we should
be including the SOA in every response, so that middleboxes can do a cache
purge (or not, befitting local policy) whenever the SOA.SERIAL moves up.

Noting that DNSSEC is still in search of its "killer app", being able to
securely invalidate cached data in a distributed, lazy fashion could be one.

--
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: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 22:47:00 +0000

> As far as I can tell, the current result of publishing a signed zone with
> all DNSKEYs of protocol = 4 is that resolvers who think the zone should
> be secured will conclude that every answer from that zone is BOGUS.

that's my reading also.

> That just doesn't seem like a good vehicle for future expansion to me.

agreed.  the whole protocol field is worthless and illconsidered as it is.
however, it can be hardcoded to 3 and left in the spec; we already abandoned
"pretty" about 200,000 miles ago, and this does not even approach "dangerous".

> If you were to argue for the removal of the protocol field from the
> DNSKEY record on the grounds that it is useless, you would get no
> argument from me.

you would get an argument from me, however.  it's doing no harm and there's
already been some early deployment with it.  before we break stiction on that
early deployment we need to prove that something is actively harmful, like
for example, prevents -ter from being even theoretically possible.  this does
not meet that standard.

> If you were, instead, to argue for language changes to the DNSSECbis
> docset to make the field more useful for something, you would also be
> quite welcome.  If you would like to describe how to use the protocol
> field for a future revision with the docs as-is, you would also be
> quite welcome.

or if you'd just like to leave it defined as it is, that would be ok w/ me,
since "useless" != "harmful".

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Jun 2004 02:16:23 +0000

> > I want to introduce a cleaner way to specify the extensions, compared
> > to using the protocol field.

so did i.  see <draft-vixie-dnssec-ter-01.txt> for one possible alternative.

> I think that the WG should discuss the merits of different ways to move the
> protocol beyond DNSSECbis.   Using the protocol field or unused flag bits
> seems like a good avenue to explore.  I don't see a great deal of
> difference between using flags or the protocol field, however.

the protocol field is essentially useless as specified.  under no
circumstances will a chance to the protocol field of DNSKEY have any
effect on the rdata layout of any RR including DNSKEY, or on the
content of other RRs including NSEC.

ed lewis sometimes talks about "the holy Q-trinity", and his arguments
are directly relevant here.  to get different answers you'll have to
ask different questions.  to get different metadata (authority/additional)
without asking a different question, you'll have to specify different
flags (like "want dnssec" and "want dnssec-ter i mean").

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jun 2004 16:13:27 +0000

> So... If I (being a security-aware resolver/validator) have:
> 
>   * followed a secure delegation (that is, I found and verified one or
>     more DS records),
> 
>   * then, when I fetch the child's DNSKEY RRset, I am able to match
>     *all* of the DS records in hand to DNSKEY RRs,
> 
>   * yet none of them are usable (i.e., proto=4).
> 
> I am thinking that one could securely conclude that this was the
> intent of the zone publisher and thus am comfortable treating this
> delegation as an Insecure delegation.
> 
> I am presuming that the childs DNSKEY RRset is unable to be
> validated, although that may not matter greatly.

that's a tautology.  you won't be able to use the keys necessary to
validate the self-signature on the keys.  so in fact, the inability
to validate the dnskey rrset will be the driving issue.

> Another way to ask this question: Is there any way for an attacker to
> downgrade a zone using this technique?

i don't think so.

> I can see that if, for instance, one did not require that all of the
> DS records match proto>3 keys, you would have a problem: the parent
> could have one DS record for a proto=4 key and one for a proto=3 key,
> and that attacker could have stripped (or altered) the childs proto=3
> key, thus downgrading the zone.

that's similar to all forms of "can corrupt the secure part of the zone"
attacks, and isn't new with (proto>3).

> > It's yes, if you are willing to accept the parent's RRSIG validity
> > time as important, it's no if you want to hear from the child.
> 
> > Maybe it is yes.  If the parent has a DS RR set that is now valid,
> > and points to bad keys (in the eyes of the resolver), but the child
> > has a fresher set that has some good keys - can the resolver ever
> > make use of them?  I think not, because there's no reason the
> > resolver will get "pointed" to the "good" keys in a verifiable
> > manner.
> 
> I think that you are correct.

me too.  but it's worth noting that this is a protocol failing, not an
attack vector.

> So far, using proto>3 (or Simon's DNSKEY flags) looks somewhat
> promising to me as an alternate way to do DNSSEC-ter.  I will note
> that this technique might (slightly) increase the complexity of the
> validator.  Without this technique, a validator will always be able to
> determine the security status of the child just by looking at the
> parent's delegation point.  With this technique, it would have to be
> able to make this distinction after fetching the child's DNSKEY set.
> I cannot tell if this would present a problem.

i think it's a problem, and it leads me to the opposite conclusion.  the
proto field is worthless for -trans, simply because not every metadata rr
has it.  by the time you've gone looking for the information you need to
know to determine whether you should trust what you saw, you already had
to trust it to do the looking, so what you find is a wider source of
possible failures, but not a wider source of possible successes.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Jun 2004 22:45:02 +0000

> ... we need to determine if 1) signaling DNSSEC-ter in DNSKEY is
> feasible (so far, looks like to me), and 2) desirable.  That is, would
> using proto=4 or DNSKEY flag bits as a signaling mechanism be better
> than TCR?
> 
> Then we can figure out whether or not we wish to revive that IANA
> registry or do something else.

on the one hand, yes and no.  it's borderline feasible, but not desireable.
(and since this isn't [email-masked], i don't have to explain my reasons.)

on the other hand, the decision as to whether to revive the closed iana
registry for dnssec protocol identifiers can come much later, after the
decision of which transition mechanism is right for bis->ter.

right now all we have to decide is whether there IS a way to go bis->ter;
we don't have to actually select one, and we don't need to reopen an IANA
registry for it.

---

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: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 00:21:08 +0000

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

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

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".
> 
> Not the most flexible assumption, IMHO.

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

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

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

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

> ...
> Well, I'll ask the question in a more straightforward manner.  Are we 
> 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: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 19:52:58 +0000

> By "publish" I mean: make available on the Internet.  Which I think is
> a fairly normal usage of the term.
> ...
> 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.

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.
> 
> 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 think we have to presume that there aren't until we come up with one.

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

i understand.

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

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

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

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