Subject: DNSSECbis Questions Update

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Nov 2003 10:07:30 +0100

Colleagues.

DNSSEC editors questions list.

Below is the updates complete list of questions. I've added text there
where there are status changes with respect to my previous posting
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01983.html)

The list of questions. 
 
 Q1 - resolved
 Q2 - resolved
 
      Although marked as resolved we never declared what the actual
      consensus on this issue is. Hereby we fix the omission:

      The original question is:

      Should we move DSA to "optional" and have RSA/SHA1 be the only
      mandatory to implement algorithm? *Consensus? *
   
      _most_ of the discussion concentrated in the thread starting at:
      http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01770.html 

      The consensus is that DSA should be moved to OPTIONAL and that the
      term OPTIONAL is to vague. RFC2119 language is to be added e.g:

        RSA	- Mandatory  (MUST be implemented)
        DSA	- Optional   (SHOULD be implemented)

 Q3 - resolved
 Q4 - mistake in numbering, there is no Q4
 Q5 - resolved 
 Q6 - resolved
 Q7 - resolved
 Q8 - resolved 
 Q9 - resolved
 Q10 - resolved
 Q11 - resolved
 Q12 - resolved
 Q13 - resolved
       But note that this question has been revisited in Q21.  
 Q14 - resolved
 Q15 - resolved
 Q16 - resolved
 Q17 - resolved

Please reply to these questions in-thread. Shortly after this list 
has been posted we will post follow-ups on each individual question
indicating what has been listed below.

 Q18: RRsig TTL violating 2181

      Default action, based on sense of the room at IETF58, is to permit
      the TTL of SIG RRs with same ownername and CLASS to be different and
      to have the TTL of the SIG RRs bound to the TTL of the TYPE of the
      RR they sign.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

 Q19: Suppression of duplications

      This issue is about the canonicalization process by the signer and
      the verifier.

      Duplicates are specifically forbidden. On the list there have been
      several opinions with regards to how to deal with this issue.

      We propose the following text as consensus position:

      Duplicate RR records are not allowed exist according to
      [RFC2181]. Implementations MUST therefore treat duplicate RR
      records as protocol errors. Signers and verifiers MUST
      canonicalize duplicate RR sets by removing duplicate RRs from
      the set if the implementation is designed to be liberal in
      handling protocol errors.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

  Q20: Expansion of wild cards in the authority section.

      Default action, based on sense of the room at IETF58, is to not
      expand the owner names of e.g. wildcard  NSEC RRs.
     
      If there is no further prohibitive objections by December 5 this 
      will be taken as consensus of the working group.

  Q21: Caching and reuse of NSEC RRs

      Default action, based on sense of the room at IETF58, is to
      change the text not to strongly prohibit any reuse of cached
      NSEC RRs, but to allow, and not encourage, (MAY language) reuse
      to synthesize negative answers for which QNAME, QLASS has an
      NSEC RR of same ONAME and CLASS in cache that proves the non
      existance of QTYPE.

      If there is no further prohibitive objections by December 8 this 
      will be taken as consensus of the working group.

  Q22: Failure Mode for compressed names. 

      What should the failure mode be if compressed names are
      encountered in RRs other than the "well-known" RRs; Should the
      verifier be liberal or fail. (Remember compression is only
      allowd for "well known RRs, RFC3597 section 4 and RFC1123)

      The sense of the room at IETF58 that senders should not send RRs
      with compressed data and receivers should "not throw a fit".

      Since, in contrast to Q19, the canonicalization for the signer
      and the verifier are specified (records section 6.2) so the
      question is if the "robustness principle" should be specified at
      all?

      If you think that there should be language to specify how to
      apply the robustness principle for when RRs other than the "well
      known" RRs are compressed than please supply text to go into one
      of the DNSSECbis draft.

      Default action will be not to add recomendations about compression
      and decompression before sending or after receiving. 

      This issue will be evaluated Mon 8 Dec.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

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