Subject: Re: Q-03: inclusion of KEY records in additional records section

From: David Blacka <[email-masked]>
Date: Wed, 12 Feb 2003 19:39:48 -0500

On Wednesday 12 February 2003 02:21 pm, Ólafur Guðmundsson wrote:
> </chair>
> <DS document editor>
> 
> Issue: Is there need to specify that KEY records be placed in additional
> section on certain queries/responses.
> 
> Q: Can the DS document outlaw the rules from 2535 that requires
> inclusion of KEY in additional section ?
...
>     (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
>     name (perhaps just a zone key) SHOULD be included as additional
>     information if space is available. If not all additional information
>     will fit, type A and AAAA glue RRs have higher priority than KEY
>     RR(s).

Hmm.  I must have initially misread this section.  I more or less 
internalized it as "return the KEYs in the ADDITIONAL section when 
returning SIGs that need to be verified with those keys."  Which, of 
course, isn't what it says at all.  But that is what made sense to me.  
Then, in a world where there was no truncation, a resolver would get back 
all of the info it needed to validate the record in a single round trip.  
This was before DS was introduced, of course.

Given this rule, it looks to me that the only case where one would *not* get 
the zone apex keyset back (barring truncation) is a referral.  NXDOMAIN has 
the zone SOA, postive and NODATA responses have the zone's NS set.  Maybe 
I'm missing something.

> DS document eliminates the NULL-KEY and replaces its role with a rule
> requiring NXT in authority section of referrals.
> 
> Some Justifications for eliminating rule 1:
> a. There is no need to push NULL KEY records anymore
> b. The rule is complex in implementation as KEY is the lowest priority
>     RRset to be included in additional section.
> c. The rule does only partially accomplishes its intent (see example 
below)
> d. The rule makes negative answers much bigger as the SOA in authority 
section
>     triggers the rule.
> e. A security aware resolver should know what information it needs and be 
able
>     to ask for multiple RRsets in parallel.
> f. The information is going to be redundant in many cases.

It seems to me that with DS, this rule should be changed somehow.  We can 
either eliminate it or strengthen it.  By "strengthen", I mean make it 
return the zone KEY rrset in referral cases as well.

Eliminating the rule (never returning KEY rrsets in the additional section) 
optimizes for code complexity and message size at the expense of round 
trips.

Strengthing the rule does the opposite: optimizes for round trips at the 
expense of code complexity and message size.

I'm not sure which is right.  At the moment I would probably vote to 
eliminate the rule.  Smaller messages and more predicable client behavior 
seems better than fewer round trips at the moment.

-- 
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: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 20 Feb 2003 10:36:15 -0500

>inclusion of KEY in additional section ?

Does anyone care if I specify in the DS document that KEY RR SHOULD NOT
be placed in additional section ?

This will simplify DNSSEC implementations, reduce packet sizes and
avoid repeated redundant information.

         Olafur

>Background:
>
>RFC2535 Section 3.5 says:
>    An explicit request for KEY RRs does not cause any special additional
>    information processing except, of course, for the corresponding SIG
>    RR from a security aware server (see Section 4.2).
>
>    Security aware DNS servers include KEY RRs as additional information
>    in responses, where a KEY is available, in the following cases:
>
>    (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
>    name (usually just a host RR and NOT the zone key (which usually
>    would have a different name)) SHOULD be included if space is
>    available.  On inclusion of A or AAAA RRs as additional information,
>    the KEY RRset with the same name should also be included but with
>    lower priority than the A or AAAA RRs
>
>
>Rule 2 is obviously there for optimization reasons and was put there
>to push out application (IPSEC) keys. As applications are now directed
>to get their own key RR type and NOT place any additional section
>processing requirements on DNS, the value of this rule is
>operationally minimal.
>
>The first rule is more interesting and is focused at the needs of
>DNS protocol elements. There are two reasons for this rule,
>1. Optimization: attempt to distribute KEY RRsets with fewer round trips.
>2. NULL KEY push: RFC2535 has NULL-KEY residing in the parent zone for
>    unsecured delegations. The rule above forces the push of this KEY set
>    along with the NS set in referrals.
>
>c. The rule does only partially accomplishes its intent (see example below)
>d. The rule makes negative answers much bigger as the SOA in authority section
>    triggers the rule.
>e. A security aware resolver should know what information it needs and be able
>Example showing why the optimization does not work in a common case.
>This is an example in secure universe.
>Q: a.b.c.d.example.   TXT   (all zones are one label deep).
>Server 1: is authoritative for example.
>Server 2: is authoritative for d.example.
>Server 3: is authoritative for c.d.example.
>Server 4: is authoritative for b.c.d.example.
>
>
>Trace (QN: query name, QT: query type, QS: server queried)
>R: QN: a.b.c.d.example. QT: TXT   QS: 1
>S1:
>    AU: d.example.   NS  2
>        d.example.   DS
>        d.example.   SIG(DS)
>
>R: QN: a.b.c.d.example. QT: TXT  QS: 2
>S2:
>    AU: c.d.example. NS 3
>        c.d.example. DS
>         c.d.example. SIG(DS)
>
>R: QN: a.b.c.d.example.   QT: TXT  QS:3
>S3:
>    AU: b.c.d.example. NS 4
>        b.c.d.example. DS
>         b.c.d.example. SIG(DS)
>
>R: QN: a.b.c.d.example.   QT: TXT  QS:4
>S4:
>    AN: a.b.c.d.example.   TXT
>        a.b.c.d.example.   SIG(TXT)
>
>In order to validate the chain the resolver still needs to query for
>KEY's for example., d.example., c.d.example., b.c.d.example.
>
>         Olafur
>
>--

---

From: David Blacka <[email-masked]>
Date: Wed, 19 Mar 2003 23:45:05 -0500

> seems better than fewer round trips at the moment.

I've changed my mind.  I now think that servers SHOULD attempt to send the 
KEY RRs in the additional section.  That is, I think that we should 
strengthen the rule rather than eliminate it.  My reasoning is that:

  * the code complexity of doing this is pretty minor,
  * optimizing for fewer round trips makes sense: bandwidth will increase 
over time, but we cannot exceed the speed of light,
  * since the client (via EDNS0) controls the max size of the response and 
the key RRs can be silently truncated, the extra size of the message should 
do no harm.

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 20 Mar 2003 22:44:21 +0100

--On Wednesday, March 19, 2003 23:45:05 -0500 David Blacka
<[email-masked]> wrote:

> I've changed my mind.  I now think that servers SHOULD attempt to send
> the  KEY RRs in the additional section.  That is, I think that we should 
>   * since the client (via EDNS0) controls the max size of the response
> and  the key RRs can be silently truncated, the extra size of the message
> should  do no harm.

This was also the conclusion arrived at during smalltalk during the
pre-IETF DNSSEC workshop. 

I am a strong supporter of the policy of including KEY records as
early/often as possible. Minimising number of RTT iterations is a major
speed hack, in my humble opinion. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 24 Mar 2003 10:55:21 -0500

<DS document editor>

I'm not trying to be stubborn about this, but I do not see the
benefit of the current rules for inclusion of KEY RRset in
additional section.

Can some resolver writers please speak up on this issue?

> >   * the code complexity of doing this is pretty minor,

Agreed on the server side. On the resolver side there is no difference
as the resolver MUST be able to look up any missing information.

> > over time, but we cannot exceed the speed of light,

My assertion is that in most common cases there is NO savings,
see the example below.

> > and  the key RRs can be silently truncated, the extra size of the message

I agree 100%.

>speed hack, in my humble opinion.

RFC2535 specifies 4 cases where KEY records are to be placed in
the additional section:  SOA,   NS, A, AAAA

Do you support the rule for all four or a subset ?

Given the example below, where is the benefit?

>KEY's for example., d.example., c.d.example., b.c.d.example.

Just to be fair, cases where there is benefit:
- negative answers, the SOA rule saves one query[1].
- when same server has child and a ancestor, during backtracking to
   the known KEY RRset, NS rule will save query KEY RRset, but DS sets have
   to be explicitly looked up.
- Priming query for root, NS and KEY sets arrive in one packet
   (if the signed KEY set is small enough to fit with the
    signed NS set and glue).

My assertion is that a security aware resolver when it sees a DS on a
referral (for <zone X>) it SHOULD issue two queries in parallel:[2]
         one following the tree
                 QN: <qname>  QT: <qtype> QS: <one of zone X NS>
         second one asking for the KEY RRset of the zone just discovered.
                 QN: <zone X> QT: KEY  QS: <one of zone X NS>

If resolver does this, users will not see any speed difference.
If the resolver has the KEY set for <zone X> there is no need to ask
the second question.

To avoid the second lookup the following rules can help:
         "referral SHOULD include the covering KEY RRset"
This is saying that the KEY RRset signing DS or NXT is placed in the
additional section.

         "always include covering KEY RRset."

but this is not what the 2535 rules are saying.

         Olafur

[1]. In the case of negative answers resolver will frequently have
learned the KEY previously. What the percentage is unknown (at least
to me).

[2] One of the discussions the comes up when people are writing DNSSEC
resolver is optimize for network or crypto delay?
The argument is if you optimize for network then you may perform unneeded 
crypto, the second case all crypto validation takes place when it is
known that there DS +KEY chain to the answer.
There is no one right answer.

---

From: David Blacka <[email-masked]>
Date: Mon, 24 Mar 2003 11:21:37 -0500

> benefit of the current rules for inclusion of KEY RRset in

I agreed with this.  The current rules do not make sense in light of DS.

> My assertion is that in most common cases there is NO savings,

My assertion is that there may be savings, and including the KEY RRset does 
no harm (since it can be silently truncated).

> Do you support the rule for all four or a subset ?

A superset.

> If the resolver has the KEY set for <zone X> there is no need to ask

Wait a minute.  Parallel queries are a pretty nice client strategy, but it 
isn't particularly optimal for servers.  However, if the standard 
recommends a parallel query strategy, then including the KEY RRset is 
certainly less attractive.
 
> but this is not what the 2535 rules are saying.

Correct.  The DS document needs to change the 2535 rules.  I am arguing 
that it should be changed to this rather than its opposite.

Always including the covering KEY RRset makes sense to me.  Essentially, 
you include the KEY RRset as soon as there is a signature that would need 
the keys in order to verify.

As a caveat, however, it should be pointed out that without more 
operational experience, it is hard to tell what approach is best.  If a 
significant percentage of DNSSEC responses get the KEY RRset truncated, 
maybe parallel queries are the way to go, and servers should not waste 
their time trying to stuff the KEY RRset into the additional section.  If 
the larger UDP responses more frequently fragment, perhaps parallel 
queries are also ultimately kinder to the network.  Or maybe not.

---

From: Rob Austein <[email-masked]>
Date: Mon, 24 Mar 2003 13:38:46 -0500

Three issues with putting stuff in the Additional section as a
performance optimization are:

- Making sure that the relative priorities of the various kinds of
  stuff that go into the Additional section is totally clear (ie,
  which goes in first);

- Making sure that the rules for when the TC bit should and should not
  be set are totally clear; and

- Making sure that the rules for what the resolver should do about all
  of this is totally clear.

There is text on this in the DNSSECbis drafts, please read it and tell
us whether we got it right.

---

From: Juergen Pfleger <[email-masked]>
Date: Tue, 25 Mar 2003 12:22:51 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> > the additional section:  SOA,   NS, A, AAAA

I think, adding the KEY RRset to these additional sections is enough.

> >                  QN: <zone X> QT: KEY  QS: <one of zone X NS>

Before a resolver enters section 4 (RFC 1034 5.3.3. rsolver algorithm (analyze section)) he must know the
 sectstat of the current zone (ver.secure or insecure). 
(A magic logic has to be added between section 3 and 4 RFC1034 sect 5.3.3)
That means , check if i key should be there . If yes, find the key in (cache or packet?) or query for it.
If there is now key (but expected) mark server as lame , try next AA server for this zone.

>From my point of view: the resolver should query ahead at the delegation point to get an
AA answer for the NS record. (if certain logic is added to the resolver this may also minimize the 
lame delegations effect or security lameness ). The second reason to do is that we need an authoritative Key 
to check if the DS RRSet is pointing to the right key id before we go ahead.

> >          "referral SHOULD include the covering KEY RRset"
I agree 100%

juergen pfleger
[email-masked]
NP-Intern