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

[Alfred Hönes <[e-mail]>]

Matthijs,

thanks for dealing with my comments so expeditiously.
(This extends to the other review comments as well.)

Please see a few follow-up remarks inline below.


On 11 Apr 2012 15:47:33 +0200, Matthijs Mekking wrote:
> Hi,
>
> On 04/05/2012 12:41 AM, Alfred Hönes 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.

So will I, again.


>> (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?

Admittedly,  "major DNS implementors" would have been better than
"majot DNS implementations" at this stage.

However, quoting from NIST SP 800-81r1, "Secure Domain Name System
(DNSSEC) Deployment Guide", (April 2010), page 9-4:

                        "[...]  The migration path for USG DNSSEC
     operation will be to ECDSA (or similar) from RSA/SHA-1 and
     RSA/SHA-256 before Septhember 30th, 2015.

... and from the same document, on page 9-6:

    "The use of RSA in DNSSEC is approved until the year 2015.
     By this time, it is expected that Elliptic Curve Cryptigraphy
     will be specified in the DNSSEC.  USG DNSSEC administrations
     should plan to migrate to the use of ECDSA (or similar) when
     it becomes available in DNSSEC components."

... one can see that there are strong market forces at work.
The commercial pressure to qualify for USG (U.S. Government) use
of networking components and software will likely lead to widespread
support soon.  There's nothing like "(or similar)" in view currently
as an alternative.
The repeated, IMHO non-rational fear of actual applicability of
patent claims is not justified; the EC groups chosen have been
selected carefully to make it possible to avoid the specific
optimizations for GF(2^n) based EC computations that in fact *might*
be covered by some patent claims -- see RFC 6090 for the detailed
report that all we need is based on academic publications that
predate the said patent applications.


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

Agreed.

The idea was to raise awareness among the reader community for
upcoming important developments, not to perform an evaluation,
and this aim is achieved with that text.


>> ...
>>
>> (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".

That's a clever choice; "name" is more neutral, and together with
"FQDN" (where applicable) looks/sounds much better in the context
of the I-D.


>
> Best regards,
>   Matthijs


Best regards,
  Alfred.