DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-13

[Ballot comment]
This is a very nicely written set of documents!

draft-ietf-dnsext-dnssec-records-09: in all of the following I'm assuming that the values described are NOT octal since one of the values (48) clearly isn't a valid octal number.  An RFC Editor note would be an appropriate if others agree that this clarity would be helpful.

Section 2, "The Type value for the DNSKEY RR type is 48": please note if "48" is to interpreted as a decimal or hexadecimal number.

Section 3, "The Type value for the RRSIG RR type is 46": please note if "46" is to interpreted as a decimal or hexadecimal number.

Section 4, "The type value for the NSEC RR is 47": please note if "47" is to interpreted as a decimal or hexadecimal number.

Section 5, "The type number for the DS record is 43": please note if "43" is to interpreted as a decimal or hexadecimal number.

Section 7: it may be helpful to note here that type values are traditionally represented as decimal numbers.  I know this is common knowledge among experienced implementers, but it might not be so clear to a newbie.

[Ballot comment]
Comments received from the ops directorate by Pekka Savola:

draft-ietf-dnsext-dnssec-intro-12.txt:

Security considerations lists a number of threats, but does not
discuss whether they have been fixed or mitigated at all (e.g.,
relating to dynamic updates and signing) [possibly in other
documents].  It might not hurt to be a bit more explicit on this.
[Similarly, maybe some of this text could be included in the DNS
security analysis document as well...]

draft-ietf-dnsext-dnssec-protocol-08.txt:

A couple of relatively minor comments.

  This document obsoletes RFC 2535 and incorporates changes from all
  updates to RFC 2535.

==> shouldn't this doc also obsolete some of these other documents
whose only purpose was to update 2535?

4.1  EDNS Support

  A security-aware resolver MUST include an EDNS [RFC2671] OPT
  pseudo-RR with the DO [RFC3225] bit set when sending queries.

  A security-aware resolver MUST support a message size of at least
  1220 octets, SHOULD support a message size of 4000 octets, and MUST
  advertise the supported message size using the "sender's UDP payload
  size" field in the EDNS OPT pseudo-RR.

==> I'm slightly concerned by this. It seems to mandate that the
implementations MUST advertise the (maximum) supported value, not
necessarily the value they deem to be best (e.g., if this would be
tied to the PMTU), or the one configured by the administrator.  Seems
like a wording issue..

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

This is very close to the limit for a DISCUSS, given the lack of clarity in the obsoletes/updates section..... but I'm just giving the comment for now.

Spencer's review:

My perspective: not a Genius of DNS, reading for ease of use of the
specifications.

The good news: All three of these documents are of high
quality. PROTOCOL and RECORDS are very close. I have one question -
these two documents, taken together, describe the DNSSEC protocol
workings - why do they have two different security sections? (Also,
neither matches INTRO's security section, but that makes more sense to
me - it's probably OK for INTRO to take a broader view.)

All three documents already share a single Acknowledgements section,
and making sure security considerations are consistent and complete is
a lot more important. If these sections are combined into one
occurance, it would be OK to do the same thing with IANA
considerations. But everything else for PROTOCOL and RECORDS is
Auth-48.

The bad news: INTRO is "On the Right Track, but Still Needs Work".

- I can't imagine the RFC Editor or the average reader getting what's
  obsoleted and what's updated right, based on the Introduction. What
  could "this document and its two companions update AND obsolete"
  possibly mean? This section needs a lot more clarity.

- In Section 3, "These services protect against MOST of the threats to
  the Domain Name Service described in" - the authors understand what
  this means a lot better than almost anyone reading it; this is the
  last chance to clearly spell out what's still an exposure.

- NIT - It would be nice to spell out what each record type is at the
  top of page 8, when they are introduced. The authors spell them out
  later, but this is the first place they appear.

- Top of page 9 - this paragraph takes forever to FINALLY say
  "Therefore the receiver must be configured with at least one trust
  anchor" in a very confusing path along the way. The entire
  paragraph, to this point, could be chopped and it would be an
  improvement.

- Section 6 - there's some discussion about problems with recursive
  name servers and proxies, but the problem really seems to be about
  NATs. Which is it? Just needs to be clearer in the second paragraph.

- NIT - Section 7 - It would be nice to show references for SIG(O) and
  TSIG in the second paragraph. It would be nice to spell out "AD bit"
  in the third paragraph.

PROTOCOL NITS

- Last sentence of the abstract - does this document obsolete all
  updates to RFC 2335? If so, better name them out if we expect the
  RFC Editor to get this right (and the readers to understand
  it). (Same comment applies to RECORDS).

- Starting in 3.2.2 there are a few (at least a couple) mentions of
  the "sense of the CD bit". I have no idea what this means, unless
  it's the SETTING of the CD bit. Is this normal terminology in the
  Land of DNS?

- Section 4.2 - s/strips of/strips off/

- Section 5.6, first paragraph - s/example the/example of the/

RECORD had no NITS, except for the "last sentence of the abstract"
(same NIT as PROTOCOL).

The authors deserve special thanks for the excellent examples in
PROTOCOL and RECORDS.

[Ballot comment]
Great documents, yes.

There are two terms used throughout the document set that I think could stand to have a strong definition (perhaps in Section 2 of dnssec-intro): "zone apex" and "authoritative RRsets". I'm sure the authors feel that both of these terms are in common use in the DNS community. However, this document set introduces a lot of MUST-strength language that depends on the understanding of these terms; consider the 2nd to last paragraph of dnssec-protocol 2.2 for an example of both, and look to the first sentence of 2.2 to see why a good understanding of these terms is necessary to avoid contradictory interpretations. I have already experienced one reader using the first sentence of 2.2, for example, to argue that NS records are always signed, presumably because of their interpretation of 'authoritative'. I don't think that the description of 'authoritative RRsets' in rfc1034 4.2.1 can serve as a precise enough definition, anyway. So, please do provide either a pointer to a place where these terms are defined, or provide a definition strong enough that the meaning of these MUST statements will be clear.

[Ballot comment]
Section 5.2 of draft-ietf-dnsext-dnssec-protocol-08 says:
  :
  : A strong cryptographic digest algorithm ensures that an adversary can
  : not easily generate a DNSKEY RR that matches the digest.
  :
  It would be more correct to say:

    Use of a strong cryptographic digest algorithm ensures that it is
    computationally infeasible for an adversary to generate a DNSKEY
    RR that matches the digest.

  Section 2 of draft-ietf-dnsext-dnssec-records-10 says:
  :
  : A resolver can then use the public key to authenticate signatures
  : covering the RRsets in the zone.
  :
  The RRsets are authenticated, not the signatures.  Therefore, it would
  be better to say:

    A resolver can then use the public key to validate signatures
    covering the RRsets in the zone, and thus authenticate them.

[Ballot comment]
Section 5.2 of draft-ietf-dnsext-dnssec-protocol-08 says:
  :
  : A strong cryptographic digest algorithm ensures that an adversary can
  : not easily generate a DNSKEY RR that matches the digest.
  :
  It would be more correst to say:

    Use of a strong cryptographic digest algorithm ensures that it is
    computationally infeasable for an adversary to generate a DNSKEY
    RR that matches the digest.

  Section 2 of draft-ietf-dnsext-dnssec-records-10 says:
  :
  : A resolver can then use the public key to authenticate signatures
  : covering the RRsets in the zone.
  :
  The RRsets are authenticated, not the signatures.  Therefore, it would
  be better to say:

    A resolver can then use the public key to validate signatures
    covering the RRsets in the zone, and thus authenticate them.

[Ballot comment]
A *very* nice set of documents.  I'd almost want the same treatment for 1034/1035 and their updates, but I'm afraid I'd be lynched for suggesting it...

Some minor comments.
draft-ietf-dnsext-dnssec-protocol-08.txt Section 4.1: a pointer should be added to Section 3 of RFC 3226, noting that on IPv6 packets over 1K SHOULD be fragmented unless the PMTU is known.

draft-ietf-dnsext-dnssec-protocol-08.txt Section 4.7: it occurs to me that perhaps there should be some text explicitly permitting caching the result of a signature check, regardless of whether it suceeded or failed.  That is, the input would be an octet string and a public key; the output would be a yes/no answer.  If an RRset including RRsig was an octet-for-octet match for the cached version, and the public key was the same, the result of doing the hash and exponentiation will be the same.  It might (repeat, might) be more CPU-efficient to store this, rather than redoing the calculation.  This is independent of the RRset TTL, though a change in RRset's octet string representation would be grounds for deleting that entry from the cache.  (This is an implementation efficiency issue; I suggest it only because of the language warning against caching signatures past the TTL expiration.  This also applies to 8.1 of draft-ietf-dnsext-dnssec-intro.)

draft-ietf-dnsext-dnssec-records: 3.2: add a note about YYYYMMDDHHmmSS being exactly 14 digits, and thus distinguishable from any 32-bit number

[Ballot discuss]
draft-ietf-dnsext-dnssec-records-09: in all of the following I'm assuming that the values described are NOT octal since one of the values (48) clearly isn't a valid octal number.  An RFC Editor note would be an appropriate if others agree that this clarity would be helpful.

Section 2, "The Type value for the DNSKEY RR type is 48": please note if "48" is to interpreted as a decimal or hexadecimal number.

Section 3, "The Type value for the RRSIG RR type is 46": please note if "46" is to interpreted as a decimal or hexadecimal number.

Section 4, "The type value for the NSEC RR is 47": please note if "47" is to interpreted as a decimal or hexadecimal number.

Section 5, "The type number for the DS record is 43": please note if "43" is to interpreted as a decimal or hexadecimal number.

Section 7: it may be helpful to note here that type values are traditionally represented as decimal numbers.  I know this is common knowledge among experienced implementers, but it might not be so clear to a newbie.

Reissued LC to deal with normative reference to Informational RFC:

Note: Update to the in-progress Last Call. dnsext-dnssec-records
contains a normative reference to (Informational) RFC 3548. Such a
reference is not normally permitted from a Standards Track document,
unless the need for this is explicitely called out during the Last
Call and is accepted by the community (i.e., per
draft-ymbk-downref-03.txt). This note makes explicit the intention to
reference RFC 3548 in a normative fashion.

Reissued LC to deal with normative reference to Informational RFC:

Note: Update to the in-progress Last Call. dnsext-dnssec-records
contains a normative reference to (Informational) RFC 3548. Such a
reference is not normally permitted from a Standards Track document,
unless the need for this is explicitely called out during the Last
Call and is accepted by the community (i.e., per
draft-ymbk-downref-03.txt). This note makes explicit the intention to
reference RFC 3548 in a normative fashion.

[Note]: '2004-09-03: AD review uncovered only minor issues, will start IETF
LC. Note: the following documents will be processed together as a set:
draft-ietf-dnsext-dnssec-intro-11.txt
draft-ietf-dnsext-dnssec-protocol-07.txt
draft-ietf-dnsext-dnssec-records-09.txt' added by Thomas Narten

From: Thomas Narten
To: Olafur Gudmundsson , Olaf Kolkman
cc: Margaret Wasserman , scott.rose@nist.gov,
    masseyd@isi.edu, sra@isc.org, mlarson@verisign.com,
    roy.arends@telin.nl
Date: Fri, 03 Sep 2004 16:20:58 -0400
Subject: AD review of DNSSECbis

I'm very pleased to say that I've reviewed these documents and they
seem to be in really good shape. I can't remember the last time I
reviewed a 3-document set of this complexity and felt this way. They
are clear, well-written, and I didn't even find any of the more common
nits that I seem to still find when reviewing documents. Details of my
review below.

I'm going to go ahead and start the LC, I don't think any of my
questions/comments are that important/urgent.

Very Nice Job!

Thomas

draft-ietf-dnsext-dnssec-protocol-07:

2004-08-31: review of -7 (WG says advance)

>    authoritative RRsets in the zone.  For each private key used to
>    create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
>    containing the corresponding public key.  A zone key DNSKEY RR MUST

just so I understand (why not MUST). How does it make sense to have
signed RRSets if there is no corresponding key that can be fetched?

And later:

>    There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any).

So when is it OK not to have a corresponding DNSKEY RR for an RRSIG?

>    A DS RR SHOULD point to a DNSKEY RR which is present in the child's
>    apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
>    by the corresponding private key.

Wondering about SHOULD again, since SHOULD typically means
"implementation choice". Is the above really about
operations/configuration?

>    A security aware name server which synthesizes CNAME RRs from DNAME
>    RRs as described in [RFC2672] SHOULD NOT generate signatures for the
>    synthesized CNAME RRs.

Oh boy. Another oddity. Are such CNAMES part of the zone? and is
SHOULD NOT correct? Seems like we now have ambiguity. They might be
generated, and they might not be. Is this good?

>    o  When placing a signed RRset in the Additional section, the name
>      server MUST also place its RRSIG RRs in the Additional section.
>      If space does not permit inclusion of both the RRset and its
>      associated RRSIG RRs, the name server MAY drop the RRSIG RRs.  If
>      this happens, the name server MUST NOT set the TC bit solely
>      because these RRSIG RRs didn't fit.

If the RRSIGs are omitted, will a followup query be sent for them? If
so, the above seems fine. If not, I wonder. I.e, this is in response
to a DO request, so we know the requester implements DNSSEC.

>    o  An NSEC RR proving that there are no RRsets in the zone which
>      would have been a closer match for .

s/a closer/an exact/ ??

>    If a DS RRset is present at the delegation point, the name server
>    MUST return both the DS RRset and its associated RRSIG RR(s) in the
>    Authority section along with the NS RRset.  The name server MUST
>    place the NS RRset before the DS RRset and its associated RRSIG
>    RR(s).

Not objecting to MUST per se, but why? is this really required?
Where else in DNS is the order in a section important/required? Who
depends on it? (I don't recall seeing other kinds of ordering
constraints, so this one sticks out in my mind.)

>    Including these DS, NSEC, and RRSIG RRs increases the size of
>    referral messages, and may cause some or all glue RRs to be omitted.
>    If space does not permit inclusion of the DS or NSEC RRset and
>    associated RRSIG RRs, the name server MUST set the TC bit (see
>    Section 3.1.1).

Doesn't omission of glue also require setting TC? Above doesn't seem to
say that exactly. Should it?

>    An authoritative name server is not required to verify that a zone is
>    properly signed before sending or accepting a zone transfer.
>    However, an authoritative name server MAY choose to reject the entire
>    zone transfer if the zone fails meets any of the signing requirements
>    described in Section 2.  The primary objective of a zone transfer is
>    to ensure that all authoritative name servers have identical copies
>    of the zone.  An authoritative name server that chooses to perform
>    its own zone validation MUST NOT selectively reject some RRs and
>    accept others.

This seems to violate the idea that all authoritative server return
the same info. If the master zone is screwed up, the mirrors should
also be screwed up. Right? MAY seems to say its OK that that not be
the case. In other places (axfr clarify discussion) this philosophical
point has been an important issue.

>    the parental NSEC RR at a zone cut MUST be included zone transfers of

s/zone/in zone/

>    RRSIG RRs appear in both the parent and child zones at a zone cut,
>    and are authoritative in whichever zone contains the authoritative
>    RRset for which the RRSIG RR provides the signature.  That is, the
>    RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
>    authoritative in the parent zone, while the RRSIG for any RRset in
>    the child zone's apex will be authoritative in the child zone.
>    Parental and child RRSIG RRs at a zone cut will never be identical to
>    each other, since the Signer's Name field of an RRSIG RR in the child
>    zone's apex will indicate a DNSKEY RR in the child zone's apex while
>    the same field of a parental RRSIG RR at the zone cut will indicate a
>    DNSKEY RR in the parent zone's apex.  As with any other authoritative
>    RRs, RRSIG RRs MUST be included in zone transfers of the zone in
>    which they are authoritative data.

Hmm. So, for a caching resolver, there are two possible RRSets for the
same name, and  one doesn't know which one will be in the cache? That
doesn't seem good. Can't harm come from that (inconsistent view of
data).

>    size" field in the EDNS OPT pseudo-RR.  A security-aware resolver
>    MUST handle fragmented UDP packets correctly regardless of whether
>    any such fragmented packets were received via IPv4 or IPv6.  Please
>    see [RFC3226] for discussion of these requirements.

Seem an odd requirement to put on DNSSEC, since this is an IP stack
issue outside of an application's control.

>    Security aware resolvers MAY query for missing security RRs in an
>    attempt to perform validation; implementations that choose to do so
>    must be aware that the answers received may not be sufficient to
>    validate the original response.

Because the there may be no RRSIGs, for instance?

Also, later, I think that these may be ommitted in responses due to
space. Seems like maybe MAY isn't right then. I.e., Are we going to
have situations where server doesn't include data, resolver needs it,
but doesn't query to be sure it should have it? Seems like there might
be an issue here.

Section 4.5 is interesting, in that it basically says TTLs can no
longer be trusted, so throw data out of cache even if TTLs are
valid. This step should not be taken lightly.

>    1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY
>        RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
>        (DNSKEY RDATA bit 7) set.

wording awkward (due to MUST).

Not sure I understand this section. Had to reread several times, and
still.

>    However, a security-aware resolver may still receive a response that
>    that lacks the appropriate DNSSEC RRs, whether due to configuration

double word.

>    o  The Algorithm and Key Tag in the DS RR match the Algorithm field
>      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
>      RRset and, when hashed using the digest algorithm specified in the
>      DS RR's Digest Type field, results in a digest value that matches
>      the Digest field of the DS RR; and

a bit unclear. The digest covers the public key, among other things.
ABove, it could be read that the hash covers less. I.e., "when hashed"
refers only to the previously mentioned fields.

>    produced as a result of wildcard expansion.  The RRset expanded as
>    the similar to The corresponding RRSIG indicates the MX RRset was
>    signed by an "example" DNSKEY with algorithm 5 and key tag 38519.

can't parse

draft-ietf-dnsext-dnssec-records-09.txt:

2004-08-30 review of -09, WG says advance.

>    This document obsoletes RFC 2535 and incorporates changes from all
>    updates to RFC 2535.

Doesn't it also obsolete some other RFCs? Would be good to list them
all explicitely.

>    The presentation format of the RDATA portion is as follows:

is this a sufficent reference to "presentation format", or should this
point to another RFC as well about what this format is used for? (It
probably sufficient....)


>    [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
>              Encodings", RFC 3548, July 2003.

normative reference to information doc. Is that OK?

>    Signature Expiration and Inception field values are in POSIX.1 time
>    format: a 32-bit unsigned number of seconds elapsed since 1 January

reference??

>      transaction security (see [RFC2931]) or both.  Values 6-251 are
>      available for assignment by IETF standards action.  See Appendix A

Is this a new "policy" or a restatement of one given elsewhere? If the
former, I'm not sure why this needs to be included. If the latter,
might be good to call out that this is an addition, as none had been
previously specified.


>      bit) [RFC3757].  Bits 0-6 and 8-14 are available for assignment by
>      IETF Standards Action.

same.

>    but not completely identical to the familiar ones complement checksum

s/ones complement/ones-complement/

draft-ietf-dnsext-dnssec-intro-11.txt:

2004-08-30 review of -11, WG says advance.

Overall, well written, no big issues.

>    If a security-aware resolver is separated from the relevant
>    authoritative name servers by a recursive name server or by any
>    sort of device which acts as a proxy for DNS, and if the
>    recursive name server or proxy is not security-aware, the
>    security-aware resolver may not be capable of operating in a
>    secure mode.  For example, if a security-aware resolver's packets
>    are routed through a network address translation device that
>    includes a DNS proxy which is not security-aware, the
>    security-aware resolver may find it difficult or impossible to
>    obtain or validate signed DNS data.

add a couple of sentence giving an example of what problem might
arise?

>    If a security-aware resolver must rely on an unsigned zone or a name
>    server that is not security aware, the resolver may not be able to
>    validate DNS responses, and will need a local policy on whether to
>    accept unverified responses.

Ditto. I.e., are protocol changes that may not be supported? or is it
just that they may not suppor the necessary RRs? I.e., can current DNS
servers (if given the proper RRs) do the right thing, or just by doing
normal lookups and caching, do the right thing, or is there behavir
that they will not support that is required?

In section 10, I don't  quite follow the three document sets, e.g.,:

>    The "Digital Signature Algorithm Specification" document set refers
>    to the group of documents that describe how specific digital
>    signature algorithms should be implemented to fit the DNSSEC resource
>    record format.  Each document in this set deals with a specific
>    digital signature algorithm.

If there is such a set, why don't you list the RFCs in the set?

[Note]: '2004-09-03: AD review uncovered only minor issues, will start IETF
LC. Note: the following documents will be processed together as a set:
draft-ietf-dnsext-dnssec-intro-11.txt
draft-ietf-dnsext-dnssec-protocol-07.txt
draft-ietf-dnsext-dnssec-records-09.txt

' added by Thomas Narten

State Change Notice email list have been change to ogud@ogud.com, olaf@ripe.net, scott.rose@nist.gov, masseyd@isi.edu, sra@isc.org, mlarson@verisign.com, roy.arends@telin.nl from ogud@ogud.com, okolkman@ripe.net