[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DNSSECbis Questions Update
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>