Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 6 Sep 2005 10:03:20 +0200

Simon,
all,

All in all, this document is in very good shape and about ready to pass 
Last Call. The only issue is that I find the use of normative language as 
of RFC 2119 a little bit shaky, I think that's something that should be 
thoroughly reviewed. Here come some examples of it, together with a 
mixture of nits and issues:

* Section 2, 3rd paragraph: "only CERT RRs with the same key tag need be 
examined". Though that is absolutely true, I am missing a statement 
(security considerations?) that key tags are not unique, so tag matching 
is a necessary but not a sufficient condition.
* Section 2, 3rd paragraph: "This is only possible if the key is 
applicable to an algorithm (and limits such as key size limits) defined 
for DNS security". It's about the wording ("key applicable to a limit"). 
What about "This is only possible if the key is applicable to an algorithm 
and complies to limits (such as key size) defined for DNS security".
* Section 2, 3rd paragraph: s/SHOULD BE/SHOULD be/
* Section 3, 2nd paragraph: "the use in DNS names of characters that 
require DNS quoting which". What about "the use in DNS names with 
characters that require DNS quoting, which"?
* Section 3, 4th paragraph: "CERT RRs MUST already know" should be "CERT 
RRs must already know"
* Section 3, 4th paragraph: "owner name MAY be the same" should be "owner 
name may be the same"
* Section 3.1, ASN description: What is that strange ".&Type" after the 
x400Address definition?
* Section 3.1, 2nd paragraph: "The recommended locations of CERT storage". 
Shouldn't that be "RECOMMENDED" to be useful?
* Section 3.1, 1st example: s/uri/URI/. Besides: What about using RFC2606 
domains instead of the existing john-doe.com?
* Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for 
examples (192.0.2.0/24)
* Section 3.4, 1st paragraph: s/auxilliary/auxiliary/. Besides: What about 
including a preference in the order of appearance (simmilar to the order 
in section 3.1)? Like for instance, first looking for the fingerprint and 
then for the key ID.
* Section 7, 1st paragraph: I suggest s/MAY/may/
* Section 7, 3rd paragraph: s/it's/its/
* Section 7, 5th paragraph: "so there are no security considerations 
related to CERT RRs and securing the DNS itself". But that's not true 
anymore since you included the comments made by Ed regarding DNSSEC zone 
enumeration problems.

Best regards,
Marcos

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Sep 2005 11:03:24 +0200

> mixture of nits and issues:

Thanks, Marcos.

The RFC 2119 language issue was brought up by Edward Lewis and an
anonymous reviewer speaking through the IESG too.  I believe Edwards'
proposal, to use "ought to" is the best solution.  I haven't seen
anyone propose to enforce owner name guidelines with strong wording.

The live document, with the changes below, are available from:

http://josefsson.org/rfc2538bis/

> is a necessary but not a sufficient condition.

I added:

  Note that two different keys may have the same key tag.

If you need more text, please suggest it.

> and complies to limits (such as key size) defined for DNS security".

Changed.

> * Section 2, 3rd paragraph: s/SHOULD BE/SHOULD be/

Changed.  And the same for a "MUST BE".

> characters that require DNS quoting, which"?

Changed.

> * Section 3, 4th paragraph: "CERT RRs MUST already know" should be "CERT 

Changed to "ought to", as per Edward's suggested language.  Note that
this might be viewed as a substantial change compared to the document
that passed LC.  I view it is a language change, the old wording could
not really be technically verifiable.  If anyone objects to this
change, please speak up.

> * Section 3, 4th paragraph: "owner name MAY be the same" should be "owner 

Changed.

> * Section 3.1, ASN description: What is that strange ".&Type" after the 

Changed.

> Shouldn't that be "RECOMMENDED" to be useful?

The intention is that the owner name guidelines recommendations are
non-normative.  I don't think this change would add clarity.

> * Section 3.1, 1st example: s/uri/URI/.

Changed.

> Besides: What about using RFC2606 domains instead of the existing
> john-doe.com?

I recall that Olaf specified in the document write-up that we decided
to not do this, to preserve similarity with RFC 2538.

> * Section 3.4, 1st paragraph: s/auxilliary/auxiliary/.

Changed.

> Besides: What about including a preference in the order of
> appearance (simmilar to the order in section 3.1)? Like for
> instance, first looking for the fingerprint and then for the key ID.

I'm not sure about this.  I don't think it is useful.  My
implementations do both fingerprint and key ID lookups, but the
priority order is per-application.  Some applications doesn't have the
entire fingerprint, e.g. applications who receive OpenPGP packets and
doesn't have the OpenPGP key locally.  So you can't really implement a
priority preference like that.  Further, I believe a new last call
would be needed if we change implementation aspects like this.  I
don't see anything calling for that.  If you believe strongly in this,
please bring it up separately.

> * Section 7, 1st paragraph: I suggest s/MAY/may/

Changed.

> * Section 7, 3rd paragraph: s/it's/its/

Changed.

> anymore since you included the comments made by Ed regarding DNSSEC zone 

Right, I removed that entire paragraph.

Thanks,
Simon

---

From: Peter Koch <[email-masked]>
Date: Tue, 06 Sep 2005 11:59:20 +0200

[minor issues, resent to the list since we're past WGLC]

Simon,

two more issues:

> Following some of the guidelines below may result in the use in DNS names
> with characters that require DNS quoting, which is to use a backslash
> followed by the octal representation of the ASCII code for the character
> (e.g., \000 for NULL).

This has come up multiple times and I'm not sure about the right answer,
but section 5.1 of RFC 1035 claims that the values are decimal. Perhaps
here it's best to say "... require DNS quoting as per section 5.1 of RFC 1035"
which also covers the "\." case.

> Implementations SHOULD use the purpose-based owner name guidelines described
> in this document, and MAY use CNAMEs of content-based owner names (or other
> names), pointing to the purpose-based owner name.

change to "... use CNAME RRs at ..." since the "CNAMEs of ... owner names"
are already what's in the RDATA section, i.e. "the CNAME" is the target, not
the owner.

-Peter

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Sep 2005 13:03:31 +0200

Thanks, Peter.  I have incorporated both of these in the upcoming -05.

Regards,
Simon

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 7 Sep 2005 18:48:07 +0200

Simon,

> If you need more text, please suggest it.

That's enough, I think.

> to not do this, to preserve similarity with RFC 2538.

Fine by me

> priority order is per-application.

I still think that a guideline could be useful, for different 
implementations could lead to different results in case there were one 
CERT under the fingerprint AND a different one under the key ID. I admit 
this is a very artificial argument. Since I don't have any strong feelings 
on this and in the light of the potential need for a new LC, we just can 
leave it as it is.

Regards,
Marcos

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Sep 2005 15:07:39 +0200

> on this and in the light of the potential need for a new LC, we just can 

I'm not sure it is as problematic as you describe, every
application/implementation that uses CERT RRs will need to make an
implicit profile of the document by using one of the owner name
standards.  However, let suppose we want to address this.  What would
the preference order be?  Some applications only has the 4 octet key
id, some has the 8 octet key id, and some will have the full 16/20
octet fingerprint.  Applications can remove digits, but not add them,
so the only generally possible approach that would work for all
implementations would be 4 octet key ids.  But that create complexity
to handle the case of collisions; some applications may not want to
bother with that extra complexity, but would rather see that the
recommendation was for full fingerprints.

All in all, I think the document shouldn't go into more detail about
this.  I believe it is better to let applications profile this
document to require a particular owner name guideline instead, if
there really is a need.

Thanks,
Simon