[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DNSSEC Open Questions
Dear Colleagues,
In order to quickly resolve the open issues for the DNSSECbis edit we
want to try to get consesus on the still open issues.
The processes for this is as follows:
For each still open question on the list as posted July 14 and the new
questions (numbers 13-14-15 dated August 3) we propose a text for a
default solution. If there is no further discussion on the item before
September 1 the editors may intrepred that silence as consent and put
the solution in the document.
Below is a summary of what we suggest, we will post these individually
in the threads relevant to these discussions.
Please use this thread for discussion of the process and the
individual question-threads on the questions for discussing the
technical/editorial content. All these have subject headers like:
DNSSECbis Q-99: The issue with Bla is Foo.
The documents are in an advanced state; If you have other issues please
bring them up, preferably before last call.
Q1 - CLOSED resolved
Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only
mandatory to implement algorithm? *Consensus? *
We feel the thread leads towards making DSA optional to implement and
to have RSA/SHA1 the only mandatory to implement algorithm. We also
think all arguments been posted on the list. Please provide your yes
or no, with a consice list of technical argumenst and try not to
discuss each others arguments if they have allready been brought up
previously in the thread.
Silence will be taken as consensus with DSA optional and RSA/SHA1 as
the only mandatory algorithm.
Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the
additional section of a response? *CLOSED: Consensus seems to be in
favor of dropping requirement*
For completeness: We, chairs, declare that consensus is in favor of
dropping the requirement
Q4 - mistake in numbering, there is no Q4
Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to
"Reserved"? *CLOSED: Consensus - Obsoleted by typecode
rollover. Useless since there is still no draft describing its
use. DNSKEY and KEY would have to have differing IANA algorithm
registries.
For completeness: As far as we know there has not been discussion on
namedroppers so consensus cannot be declared, however this point is
obsoleted by the typecode rollover, the working group does not need to
have consensus on that.
Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"?
but now encompasses how servers/resolvers should interpret the CD bit
in the DNS header. * No formal consensus reached yet, discussion died
out *
We think think that this discussion needs to be completed. We propose
the following and want to gauge concensus on that proposal.
Security aware caching name servers SHOULD not cache bad data (normal
circumstances), on the other hand security aware servers SHOULD cache
data in the cases where a query for the same data is received in short
time intervalls (DOS like circumstances). Note that this kind of
caching is a form of negative caching, however the TTL vallue can not be
derived from the data and has to be set by the implementation. We will
refer to the data that is cached under these circumstances as data
from the 'BAD cache'.
If a query is received with the CD bit on, the server SHOULD in normal
circumstances disable checking for the particular query and forward
the data to the querying client. If the CD bit is set and data is
available in the 'BAD cache' it should be fetched from there. If the
CD is not set the server returns a failure. (wordcrafting is needed
here. In the current implementation this would be a SERVFAIL).
[Please respond to the content of this proposed text in the thread itself]
Q7- Should the DNSSECbis documents discuss use of preconfigured
trusted DSs in addition to preconfigured trusted KEYs? *CLOSED:
consensus is: sure, why not? *
For completeness: We declare the following consensus from the
discussion on the list: The DNSSECbis document discuss different
possibities for configuring a trust anchor.
Q8 - Should the apex allow zone KEY RRs only? *CLOSED: Consensus seems
to be no restrictions at all on KEY RR placement in a zone * besides,
DNSKEY are the zone keys now.
For completeness: We declare consensus as no restrictions at all on
DNSKEY and KEY RR placement.
Q9 - Dropping the SIG(NXT) from the NXT RRs included in the
Auth. section on wildcard and negative replies *CLOSED: Consensus
seems to be no allowing of NXT/SIG(NXT) breakup in authority
section. Truncate response *
For completeness: The consensus is that the complete set of NXT RRs is
to be included in the authority section and that the inability to
include one or more will lead to a message that is marked as
truncated.
Q10 - Silly state - some further elaboration and text will be
presented to the list at a later date.
Q11 - KEY RRs at delegation point. CLOSED: DNSKEY/KEY would be
glue. Not a DNSSEC issue about what to allow as non-auth glue. Local
policy about serving and accepting unsigned data would dictate.
We feel that based on the discussion on the list this question can not
be closed. The discussion so far can be summarized as above: DNSSEC
does not introduce any special additional specifications whether RRs
are to be treated as glue or not.
No further discussion on this item before September 1 will be taken as
consensus for this position.
Q12 - Should support for configuring multiple trusted public keys in a
security-aware resolver be a MUST rather than a SHOULD?
We will take further silence on the list as consensus for the text as
sugested in the original message.
Consensus is gauged September 1.
Q-13: Should the implementation advice regarding caching in
security-aware resolvers remain in the document?
We will take silence on the list as consensus for keeping this advice
in the document.
Q-14: Under certain circumstances, a security-aware recursive name
servers could conceivably synthesize a response to one request using
security data in its cache from a different, previous request. This
behavior is currently discouraged with SHOULD NOTs, but should it be
prohibited with MUST NOTs instead?
We will take silence on the list as consensus for a change from SHOULD
NOTs to MUST NOTs.
Q-15: Should a security-aware stub resolver be allowed to set the CD
bit on queries or should this behavior be prohibited?
Question 15 seems to be based on a editorial goof. This question will
either be clarified or obsoleted.
Olafur and Olaf
DNSEXT Chairs.
-- 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/>