Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A)

[Matthijs Mekking <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 04/05/2012 12:41 AM, Alfred � wrote:
> After a long delay, I have revisited the
> "DNSSEC Operational Practices, Version 2" I-D and performed
> a full review from scratch for the most recent draft version,
> draft-ietf-dnsop-rfc4641bis-10.

A very long delay, the wglc ended somewhere last year...

> For convenience, and to accommodate message size limitations,
> I have split my review comments into 3 parts:
> 
>   (A)  Technical flaws,
>   (B)  Editorial flaws, and
>   (C)  Editorial nits
> 
> Only the first two parts will be sent to the dnsop list,
> the bulky third part is given as fodder to the authors only.
> 
> Here we go with part (A);
> please consider to provide feedback for the items below on the list.

I have omitted all items that I have adopted without feedback necessary.
In other words, all omitted items will make the next version of the
document.

> (A)  Technical flaws
> ++++++++++++++++++++

> (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA
> 
> Given the pressure by important governmental/international
> stakeholders in support of Elliptic Curve (EC) cryptography
> and the large amount of DNS response packet space consumed
> by RSA (and DSA) keys and signatures, I strongly recommend
> to give the reader a glimpse of perspective on ECDSA usage with
> DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor
> queue in state "RFC-Editor" and already supported by major DNS
> implementations.

A glimpse perhaps, but we (the editors) think your suggested is too
strong. Also, we think that there is too little experience with ECDSA to
make good observations. Which major DNS implementations are you
referring to that have already implemented ECDSA?

> For instance, it would IMO make sense to add at the end of Section
> 3.4.1 or 3.4.2 a new paragraph like this:
> 
> |  Operators concerned with performance and key/signature size issues
> |  related to RSA and DSA usage with DNSSEC should follow the ongoing
> |  standardization -- and consequential implementation -- progress for
> |  the use of digital signature algorithms based on Elliptic Curve (EC)
> |  Cryptography with DNSSEC, which promises much shorter key and
> |  signature sizes than RSA/DSA for equivalent cryptographic strenght.
> |  In particular, the use of ECDSA with DNSSEC is now specified
> |  [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in
> |  the foreseeable future.

We would like to say that ECDSA is out of scope for Version 2 of DNSSEC
Operational Practices. We suggest the following text at the end of
3.4.1, which summarizes ECDSA and will not be discussed here.

    Also at the moment of publication, digital signature algorithms
    based on Elliptic Curve (EC) Cryptography with DNSSEC [] are being
    standardized and implemented. The use of EC has benefits in terms
    of size. On the other hand, one has to balance that against the
    amount of validating  resolver implementation that will not
    recognize EC signatures and thus treat the zone as insecure. Beyond
    the observation of this trade-off, we will not discuss further
    considerations.

> (A.8)  Section 4.3.5.1, Figure 9 -- wrong child SOA serials?
> 
> According to the prose in this section, as far as I understand it,
> the "redelegation" phase should happen with stable client zone data
> at both the old (A) and new (B) DNS operator and only change the
> parent zone -- or have I missed something important there?

The only client zone data that needs to be stable is the NS and DNSKEY
RRsets. So, the serial may be incremented during the pre-publish and
redelegation phases. However, for clarity it might indeed be better to
take over your suggestion.

> (A.9)  Section 4.4 -- technical clarification
> 
> Since RFC 2308 specified the caching behavior for negative responses,
> which arguably do not deliver "data", the text in Section 4.4 needs
> a small addition to properly represent the negative caching behavior
> as well:
> 
> OLD:
> 
>    Without DNSSEC, all times in the DNS are relative.  The SOA fields
>    REFRESH, RETRY, and EXPIRATION are timers used to determine the time
> |  elapsed after a slave server synchronized with a master server.  The
> |  Time to Live (TTL) value and the SOA RR minimum TTL parameter
> |  [RFC2308] are used to determine how long a forwarder should cache
> |  data after it has been fetched from an authoritative server.  By
>    ^^^^
>    using a signature validity period, DNSSEC introduces the notion of an
>    absolute time in the DNS.  Signatures in DNSSEC have an expiration
>    date after which the signature is marked as invalid and the signed
>    data is to be considered Bogus.
> 
> NEW:
> 
>    Without DNSSEC, all times in the DNS are relative.  The SOA fields
>    REFRESH, RETRY, and EXPIRATION are timers used to determine the time
>    elapsed after a slave server synchronized with a master server.  The
>    Time to Live (TTL) value and the SOA RR minimum TTL parameter
>    [RFC2308] are used to determine how long a forwarder should cache
> |  data after it has been fetched from an authoritative server or
>                                                               ^^^
> |  negative responses, respectively.  By using a signature validity
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    period, DNSSEC introduces the notion of an absolute time in the DNS.
>    Signatures in DNSSEC have an expiration date after which the
>    signature is marked as invalid and the signed data is to be
>    considered Bogus.

Ok, although I have made it:

> |  data (or negative responses) after it has been fetched from an
>        ^^^^^^^^^^^^^^^^^^^^^^^^
> |  authoritative server or.  By using a signature validity


> (A.10)  Section 5.1, ff. -- term "RRlabel" needs clarification
> 
> I have trouble understanding what the term "RRlabel" means and
> what precisely the draft wants to state in the text passages
> where it is used.  This term, used as a single word, is very
> uncommon and has not been used in published RFCs so far, and
> it is nowhere formally defined in this memo; yet it recurs for
> a total of 8 instances in Sections 5.2, 5.3.1, and 5.3.3.
> 
> The first occurrence is in the first sentence of the last para
> of Section 5.1, which says:
> 
> | The NSEC3 record uses a hashing method of the requested RRlabel.
> 
> If the draft wants to introduce a new term, it should precisely
> define it upon first usage (or in a terminology section).
> I also do not fully understand what "requested" means here --
> a QNAME in a DNS query? (that's not a 'label' in the sense of
> STD 13, but a FQDN); subsequent text in Section 5.2 (3rd para):
> 
> |  For large zones where there is an implication of "not readily
> |  available" RRlabels, such as those where one has to sign a non-
> |  disclosure agreement before obtaining it, NSEC3 is preferred. [...]
> 
> ... might even be understood as indicating 'request for registration'
> (via a registrar into a zone that has restrictive policies on what
> relative domain names can be registered).  That needs clarification.
> 
> But, firstly, back to the last para of Section 5.1!
> 
> Upon further investigation: what's hashed for NSEC3 aren't single
> labels, but the fully qualified domain names registered in the zone
> -- the details are specified in Section 7.1 of RFC 5155, and also
> quoted shortly in Section 5.3.1 of the draft.  And these are not
> the domain names "requested" in DNS queries (QNAMEs) -- unless these
> happen to match FQDNs for which RFC 5155 has made mandatory the
> generation of NSECe RRs (in particular, for secure delegations
> and for wildcards), or for which the Opt-out policy in force has
> chosen to generate NSEC3 records.
> Thus, as long as there is no sensical definition of the term, maybe
> "the requested RRlabels" might better be replaced by
> "the names registered in the zone".
> 
> Note that the subsequent instances of "RRlabel" in Sections 5.2
> (1st and 3rd para, 1x each), 5.3.1 (1st para, 2x), and 5.3.3
> (2nd para, 3x) will likely need text adjustments as well.

I have replaced all occurrences by "name".

Best regards,
  Matthijs

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPhYt1AAoJEA8yVCPsQCW5CoAH/1sThiCyT78pXdfORyAXe6NB
lQnpJttZh2Uw9V7Ab80mUwgS1SpMnUwmv+UGhsOza22qiW1Cx8PnKkoh5n4MyhB/
gm29+yKoCz32Ie/4RqvfQ5ZzYmMmrdKOU0KbMFE9t+6xmfdjqiIGoh/8YEhb45ve
LRF5Pmw/aKUwTESsC2PG7jycL3sFVr28ufM7rH+WqVreKcc7Jm49KV4rSA8H2nE5
FRP9O/W3EtcXLoJz0qOQ74EZlAcLKDbrIJGtlHgJwq6BR3bKnpJ0HpeVzT4Fo2dx
CkAQtRZtLTYyc1pJzD9723gzrZoccuO6g93HHNBlxvu+1r9CSuP07EQqFp2EhEk=
=Au1p
-----END PGP SIGNATURE-----