Subject: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 10 Aug 2005 14:33:39 -0400

The IESG has received a request from the DNS Extensions WG to consider the 
following document:

- 'Storing Certificates in the Domain Name System (DNS)'
   <draft-ietf-dnsext-rfc2538bis-03.txt> as a Proposed Standard

This document updates RFC 2538.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-08-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt

--
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: Edward Lewis <[email-masked]>
Date: Wed, 10 Aug 2005 16:06:56 -0400

>    <draft-ietf-dnsext-rfc2538bis-03.txt> as a Proposed Standard

Overall I think the document is well-intentioned, although I'd nit 
pick over wording here and there.  However, there is one topic that 
bothers me.

When it comes to "content based" naming I have concerns over zone 
enumeration.  (Yes, that beast.)  To the credit of the document, it 
does not require nor recommend content based names, so this isn't a 
serious critique, however this is something that ought to be 
mentioned in the security considerations section.

I.e.:

# If an organization chooses to issue certificates for it's employees,
# placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) is in
# use, it is possible for someone to enumerate all employees of the
# organization.  This is usually not considered desirable, for the same reason
# enterprise phone listings are not often publicly published and are even mark
# confidential.

That is about the text I'd recommend.

The draft could go further and state that not using DNSSEC if this is 
a concern is one option, as the certificates may have their own 
validation scheme.

Other notes...

The draft uses "should" in lower case, e.g.:

    1.  If a domain name is included in the identification in the
        certificate or CRL, that should be used.

This is likely not the same as SHOULD as is referenced at the end of 
section 1 (the RFC 2119 blurb).

I'd probably want to include more explanation in section 3 that this 
is entirely a "use case" discussion - the owner name of a CERT RR 
isn't important to the DNS at all, just important to the applications 
that deal with it.  I.e., there is no special distinction between a 
content name and a purpose name, both are just domain names.  (I 
mention this because of the confusion over the SRV record and it's 
"Name" portion of the owner name.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Aug 2005 07:59:18 +0300 (EEST)

> This document updates RFC 2538.

The abstract says "This document obsolete (sic) RFC 2538."  I assume 
that is correct, not the "updates" in the last call announcement.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Aug 2005 12:26:19 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext- 

Sorry for the late participation in reviewing this draft.  While  
dealing with issues related to MASS, it has become apparent there is  
only passing consideration given the impact user-keys may have when  
published using DNS.  One suggestion just made on the MASS mailing  
list, that could actually be encompassed by the current DKIM draft,  
was to utilize a wildcard for a key record to permit manipulations of  
selectors as a means to revoke a key.

This suggestion took the example to resolve to not only the user, but  
to each and every message sent by a system.  While this would be easy  
to implement by the sender, it may introduce undesirable burdens to  
the DNS infrastructure.  The performance consideration in this draft  
only concern that of transfer size for UDP or TCP.  Although this is  
merely repeating that of a prior draft, in light in ongoing work, it  
seems prudent to offer additional advice regarding the effects from a  
large aggregate of actively employed keys at levels involved with email.

This draft discusses the use of keys for email.  However the scale of  
email  can be enormous, where user-keys, such as those specified in  
this draft, could dramatically change the average DNS load carried  
per domain.  It would be beneficial to include a general review as to  
the appropriate level of key use in DNS.

,---
|4.  Performance Considerations
|
| Current Domain Name System (DNS) implementations are optimized for
| small transfers, typically not more than 512 bytes including
| overhead.  While larger transfers will perform correctly and work is
| underway to make larger transfers more efficient, it is still
| advisable at this time to make every reasonable effort to minimize
| the size of certificates stored within the DNS.  Steps that can be
| taken may include using the fewest possible optional or extensions
| fields and using short field values for variable length fields that
| must be included.
|
| The RDATA field in the DNS protocol may only hold data of size 65535
| octets (64kb) or less.  This means that each CERT RR cannot contain
| more than 64kb worth of payload, even if the corresponding
| certificate or certificate revocation list is larger.  This document
| address this by defining "indirect" data types for each normal type.
'---

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 30 Aug 2005 17:07:11 +0200

Hello Douglas, thanks for your comments.  I believe a general review
of the appropriate level of key use in DNS will be challenging to
produce.  As far as I am aware, there is no consensus on what the
appropriate level of key use in DNS should be.  Some believe there
will be no problems having large scale deployment of user keys in DNS.
Some fear many problems.  There is little substantial work on the
topic, but plenty of hot air.  If you (or someone else) can provide me
with some text that reflect what we can reasonable believe is sound
advice, it may be added, or at least discussed further.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 30 Aug 2005 17:11:57 +0200

> that is correct, not the "updates" in the last call announcement.

My intention has been that RFC 2538bis should "obsolete", not "update"
RFC 2538.  The updated draft contains most of the text from the
original RFC.  I don't know why the announcement says "updates".  I
don't see any point of merely making it an "update".  Thanks for
pointing this out, if it matters for the I-D state machine or RFC
process, perhaps it could be corrected by the IESG.

And btw, I have fixed the typo, and many others too.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 30 Aug 2005 17:22:29 +0200

> That is about the text I'd recommend.

Hello Edward.  Thanks for your comments, and the suggested text.  I
agree with the text and I have added it in -04.

> a concern is one option, as the certificates may have their own 

This appear to already be covered:

    By definition, certificates contain their own authenticating
    signature.  Thus, it is reasonable to store certificates in
    non-secure DNS zones or to retrieve certificates from DNS with DNS
    security checking not implemented or deferred for efficiency.

> section 1 (the RFC 2119 blurb).

Right.  I see one problem with turning those "should" into "SHOULD".
The paragraph before that says:

    <t>The recommended locations of CERT storage are as follows, in priority
      order:</t>

The key-word is "recommended".  The naming convention is not a
requirement.  Anyone can put CERT records under any silly owner name
she wants.  The document can describe which owner names leads to
practical use cases, but using RFC 2119 wording seem too strong for
me.

However, I don't feel strongly about this, and if there is consensus
that the priority ordering should be more explicit, then we could
change it.  I don't think it will improve clarity though.  The extreme
would be to forbid CERT RRs at other owner names, but I don't see us
ever going there.  This is a protocol document, not a policy document.

> "Name" portion of the owner name.)

Right, it seems we agree on the principle.  I believe this is already
clear for anyone with DNS knowledge, but if you have specific text
that would clarify this further, I'll add it.

Thanks,
Simon