Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS

From: Edward Lewis <[email-masked]>
Date: Sat, 3 Sep 2005 10:18:40 +0100

At 17:22 +0200 8/30/05, Simon Josefsson wrote:
>>  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).
>
>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.

In that case I would suggest then "ought" instead of "should." 
That's the word I have been using to avoid the RFC 2119 clashes. 
(There have been times that the IESG will send back a document that 
uses lower case versions of RFC 2119 words.)

It's all just a document process comment.  No technical meaning inferred.

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

The problem is educating non-DNS experts.  I have run afoul of that 
when speaking to non-DNS working groups.

Suggested text...

Note that this section (section 3) describes an application-based 
mapping from the name space used in a PKI to the name space used by 
DNS.  The DNS does not infer any relationship amongst CERT resource 
records based on similarities or differences of the DNS owner name(s) 
of CERT resource records.  For example, if multiple labels are used 
when mapping from a CERT identifier to a domain name then care must 
be taken in understanding wildcard record synthesis.

(Is that meaningful?  In particular, I'm reacting to the 
misconceptions about wild cards that arose in the MARID WG - as a 
"real world" example of the kind of confusion I want to avoid.  There 
was also confusion over the "Name" in the SRV record defining RFC. 
That kind of stuff.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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

--
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 10:02:47 +0200

> It's all just a document process comment.  No technical meaning inferred.

I agree with this.  I have changed some occurrences of "should" into
"ought to" in the upcoming -05, accessible via:

http://josefsson.org/rfc2538bis/

> was also confusion over the "Name" in the SRV record defining RFC. 

I don't mind adding that text, but have two problems.

First, I think we should avoid the use of "PKI", publishing
self-signed certs in DNS is perfectly fine, and the term PKI is not
descriptive of this scenario.  I would prefer "from the name space
used in a certificate".

Secondly, I don't understand what the last sentence is about.  What
problem with wildcard record synthesis are you referring to?  If this
should be mentioned, there should be some explanation or reference so
the reader can understand what is intended.

For the record, I have received some typo fixes privately, and will
submit -05 soon, which will include the changes discussed here too.
As always, the live document, as well as rfcdiff output, is available
from the web site above.

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Sep 2005 16:16:10 +0700

>descriptive of this scenario.  I would prefer "from the name space

That's okay, I understand the issue.  Admittedly, it's not one I am 
sensitive to.  I.e., I bow to your decision. ;)

>the reader can understand what is intended.

Do you mean (by the "last sentence") "For example, if multiple labels 
are used when mapping from a CERT identifier to a domain name then 
care must be taken in understanding wildcard record synthesis."?  If 
so, I mean "edward.lewis.neustar.biz" and "ed.lewis.neustar.biz" 
should not be confused for the same person at the "lewis.neustar.biz" 
point.

Or did you mean "There was also confusion over the "Name" in the SRV record..."
If so, then its in RFC 2782 says :

#The format of the SRV RR
#
#   Here is the format of the SRV RR, whose DNS type code is 33:
#
#        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
#

"Name" is not the "owner name" but "the host name" (as opposed to the 
host name as defined in RFC1123).  The problem is that apps 
developers started assuming that Name had special properties in the 
DNS, resulting in bad assumptions about the role of wildcards in DNS.

E.g. if "Name" does not exist in DNS, and there is *.example that 
matches it, _Service._Proto.*.example. did not follow from a wildcard 
expansion.

---

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

> sensitive to.  I.e., I bow to your decision. ;)

Thanks, I have added your paragraph with that modification.

> care must be taken in understanding wildcard record synthesis."?
> If so, I mean "edward.lewis.neustar.biz" and "ed.lewis.neustar.biz"
> should not be confused for the same person at the
> "lewis.neustar.biz" point.

Yes, that was what I was referring to.  Thanks for the explanation.

Regards,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2005 10:12:56 -0700

On Aug 30, 2005, at 8:07 AM, Simon Josefsson wrote:

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

Perhaps this text could be added, but I still think there should be  
attempts to better estimate the performance characteristics of DNS  
from the standpoint of a before and after perspective.  Keep in mind,  
that per-user keys offer the ability to encrypt and sign messages  
where the need for the key is not just for delivery, but also when  
the message is being read and written.  As an engineering  
organization, these affects should be estimated before wide  
deployment is attempted.  Now is the time this should be done.

-----

With tens of millions of emails sent every minute, and where the  
number of email accounts per individual is growing, adding a sizable  
user-key component per mailbox into DNS may be deleterious to the  
performance of DNS.  Due to the iterative query strategy, DNS largely  
depends upon caching in random access memory to meet performance  
expectations.  Random access memory avoids latencies found in disk  
storage that have not changed substantially, principally due to heat  
dissipation limitations.  The user-key may change the amount of  
information exchanged in DNS from a few hundred to billions of bytes  
per domain.  This increased exchange could cause a dramatic reduction  
in the ability of DNS to adequately cache information.  From a  
performance consideration perspective, the impact upon the DNS cache  
has been ignored.  No attempts have been made to estimate this impact  
when wide spread deployment occurs.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Sep 2005 18:32:10 +0000

# With tens of millions of emails sent every minute, and where the number of
# email accounts per individual is growing, adding a sizable user-key
# component per mailbox into DNS may be deleterious to the performance of DNS.

i don't agree.  publish and consume all the data you want-- DNS can handle it,
as long as you don't design around TC and TCP-fallback in the average case.

# Due to the iterative query strategy, DNS largely  depends upon
# caching in random access memory to meet performance  expectations.

no, it doesn't.  caching is not very effective, mostly due to bad
implementations and middleboxes.  authority servers today have to be
provisioned as well as they would if there were no caching at all.

# The user-key may change the amount of information exchanged in DNS from a
# few hundred to billions of bytes per domain.

bring it on.

# This increased exchange could cause a dramatic reduction in the ability of
# DNS to adequately cache information.  From a performance consideration
# perspective, the impact upon the DNS cache has been ignored.  No attempts
# have been made to estimate this impact when wide spread deployment occurs.

i have a better idea.  publish the data and expect operators and implementors
to be grownups and to cope.  dns is not some weak-kneed sissy whose back can
be thought "not strong enough to carry this load".  bring it on.  we're adding
dnssec in part so that dns can carry new, authenticity-sensitive information.
we're adding anycasted root name servers all over the world to improve system
availability.  we've added EDNS0 to increase payloads and avoid TCP more often.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2005 16:03:00 -0700

> as long as you don't design around TC and TCP-fallback in the  

Both DNSSEC and user-keys together may result in TCP-fallback or  
reliance upon the Extension Mechanisms for DNS (EDNS0).  Will EDNS0  
be a problem in some cases?  EDNS0's larger packet sizes will have  
greater impact upon networks, even when TCP is not used.

> provisioned as well as they would if there were no caching at all.

Caching of results is certainly needed to some extent.  A DNS server  
able to issue data at ever higher rates does not relate directly to  
performance, when a higher rate results in greater packet loss.

> # few hundred to billions of bytes per domain.

A six or seven order increase in payload should at least merit  
consideration.

> be thought "not strong enough to carry this load".  bring it on.

DNS is a critical and burly function that merits review when making  
major changes in the amount of data exchanged.

> we're adding

While DNSSEC is definitely needed, this does _not_ make DNS more  
robust.  DNSSEC will lower and not raise the amount of data exchanged  
before negative impacts upon overall performance of DNS and the  
network occur.

> we've added EDNS0 to increase payloads and avoid TCP more often.

While the stateless nature of DNS certainly affords ease in  
transmitting data, raising the amount and size of UDP traffic is not  
without consequence.  This merits review.  Let's not blame problems  
created on operators. : )

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Sep 2005 10:44:13 +0200

> deployment is attempted.  Now is the time this should be done.

I think we generally disagree.

First, everyone is welcome to measure a before and after performance
characteristic.  If you do this thoroughly, and report your findings,
it would be a valuable resource and we could reference it in this
document.  However, at this point, I see nothing more than
speculations here.  Keep in mind that RFC 2538 has already been
published.  It is already possible to deploy this mechanism, without
RFC 2538bis.  RFC 2538bis can only be based on what we know today, not
what we may know in a few years, so if you like to see this wide-scale
performance estimate done, please start working on it!

> performance of DNS.

The keyword here is "may".  Everything MAY happen.  Without any
evidence, I don't think it is wise to add these fearful sounding
phrases to the document.

> Due to the iterative query strategy, DNS largely depends upon
> caching in random access memory to meet performance expectations.
> Random access memory avoids latencies found in disk storage that
> have not changed substantially, principally due to heat dissipation
> limitations.

I don't understand this.  Are you saying that RAM accesses is the
bottleneck for DNS?

Thanks,
Simon

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Sep 2005 11:09:13 -0400

On 8/11/2005 3:26 PM, Douglas Otis wrote:

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

I agree with most of your concerns, but there is another factor that needs
to be considered, which is the implicit difference between data models
that are used at the personal and/or organizational level versus those
that are used Internet-wide. The IETF has to be really careful with the
latter, but it's not really a problem for the IETF (as a procedural issue)
if somebody wants to shoot themselves in the foot.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Sep 2005 10:04:50 -0700

>> On Aug 30, 2005, at 8:07 AM, Simon Josefsson wrote:

When doing a comparison of the two documents, I did notice an error  
unrelated to this topic.

+ The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
+ content that would have been in the "certificate, CRL or URL" field
+ of the corresponding (PKIX, SPKI or PGP) packet types.  These types
+ are known as "indirect".  These packet types MUST be used when the
+ content is too large to fit in the CERT RR, and MAY be used at the
+ implementer's discretion.  They SHOULD NOT be used where the entire
+ UDP packet would have fit in 512 bytes.

In RFC1035 for UDP, a message size is limited to 512 bytes, not the  
packet size as indicated in this statement.  The data-gram limitation  
is 576 bytes per RFC879.

> published.

This draft is recommending multiple owner-names and discusses use of  
wildcard record synthesis.  This was the point I found alarming when  
a method to synthesize records for every email message was described  
in MASS.  This was the reason I suggested there should be some advice  
given in the performance considerations section.  This version of the  
draft very much adds to this concern.

>   It is already possible to deploy this mechanism, without

I am not the one advocating use of this record, nor am I attempting  
to embellish use of this record.  In the absence of modeling or  
testing at projections of possible deployment, then _some_ statement  
regarding a lack of this review should be made in the performance  
section.  At least warn that this may cause foot damage. : )

> evidence, I don't think it is wise to add these fearful sounding

The attempt was to provide some motivation.  Of course DNS servers  
_can_ issue a reply for every query seen by the server.  This says  
little about the overall performance of DNS or the networks.

> I don't understand this.  Are you saying that RAM accesses is the

I was attempting to describe how there can be non-linear (cascading)  
effects when the cache becomes less effective.  The bottleneck is not  
RAM access, but rather RAM, as a resource, could be less effective  
when DNS payloads and records increase by many orders of magnitude.   
This problem gets worse when DNSSEC is deployed.  I do not share  
Paul's optimism that DNS can become a database suitable for any and  
all applications without risk, and that operators will find a means  
to cope.

-Doug

---

From: David Conrad <[email-masked]>
Date: Tue, 13 Sep 2005 11:01:48 -0700

Hi,

On Sep 12, 2005, at 10:12 AM, Douglas Otis wrote:
> The user-key may change the amount of information exchanged in DNS  
> from a few hundred to billions of bytes per domain.

The size of a particular domain in the context of caching servers  
isn't particularly relevant (at least in the caching servers I'm  
aware of).

> This increased exchange could cause a dramatic reduction in the  
> ability of DNS to adequately cache information.  From a performance  
> consideration perspective, the impact upon the DNS cache has been  
> ignored.

If you try to keep the cache the same size as today, yes, there will  
be an impact (particularly in caching servers whose memory management  
techniques are to crash when they aren't able to allocate sufficient  
memory to cache new items.  Perhaps this will finally kill off  
BINDv8?).  If there is wide scale deployment of this, caches in front  
of mail servers (and other apps that make use of user keys) will  
probably require more RAM in order to achieve the same level of  
performance they have now.

While I am not too concerned about this myself (perhaps due to who  
pays my salary :-)), I suppose it might be prudent to do a bit of  
analysis and make note of this in some sort of operational forum.   
Perhaps an "Operational Considerations of User Keys in the DNS"  
document in DNSOP?

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Sep 2005 19:53:20 +0000

# > With tens of millions of emails sent every minute, and where the number of
# > email accounts per individual is growing, adding a sizable user-key
# > component per mailbox into DNS may be deleterious to the performance of
# > DNS.
# 
# The keyword here is "may".  Everything MAY happen.  Without any evidence, I
# don't think it is wise to add these fearful sounding phrases to the
# document.

i agree.  doug has been very polite to me over the years, and so i didn't
want to accuse him of "slinging FUD" with that passage.  so, thank you :-).

# > Due to the iterative query strategy, DNS largely depends upon caching in
# > random access memory to meet performance expectations.  Random access
# > memory avoids latencies found in disk storage that have not changed
# > substantially, principally due to heat dissipation limitations.
# 
# I don't understand this.  Are you saying that RAM accesses is the bottleneck
# for DNS?

i interpretted this as a variation on the "working set size" argument against
a million-tld root zone.  basically it goes like this: supposedly, a
nameserver seeing N queries per unit time is implicitly benefitting from query
suppression due to caching, such that names from zones served by that
nameserver are being consumed N*M times, and it's considered unlikely that a
given nameserver has enough headroom to respond to all N*M queries if caching
weren't occuring at all.  there's also end-user RTT delays to be considered --
even if the name server has enough headroom, making applications wait for a
cache-miss would be an undue burden.  into this quixotic morass, we're to
suppose that an intermediate cache has a configured maximum working set size
which is in the same order of magnitude as the actual working set, such that
if we were to increase the number of names or the size of the data that was
offered for caching, the overall cache hit rate would decline, thus simulating
uncacheability.

with my high respect and regard for doug completely intact, i have to say: all
of this is just crap.  from beginning to end, there is no truth to any of it.
caching is already not happening for reasons unrelated to this; intermediate
caches either do not have a configured maximum working set size, or it's not
in the same order of magnitude as the current offered load; applications who
face high end-to-end RTT toward authority servers are already seeing it; there
is no NEW disincentive offered by the size or number of certificates or DNSSEC
metadata.  the system is NOT doing what you think it's doing, and it will NOT
fall apart as a result of implementation of any proposal i have seen here.

we could put a million, or ten million, names into the root zone, too, with no
harm to anybody.  i've said that it's safe to bet on the implementors and
operators to cope with these results.  that's because i consider it unsafe to
bet on new alternative systems to carry data as well as DNS can already do.

"crunch all you want, we'll make more."

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Sep 2005 16:18:54 -0700

> isn't particularly relevant (at least in the caching servers I'm  

I agree the size of the domain is not important, but rather the  
amount active.  This was mentioned to offer a sense of the relative  
change that could occur.  User-keys per mailbox will create a sizable  
change in the amount of active data, as well as the number of records.

>> ability of DNS to adequately cache information.  From a  
>> performance consideration perspective, the impact upon the DNS  
>> cache has been ignored.
>>
>
> If you try to keep the cache the same size as today, yes, there  
> will be an impact (particularly in caching servers whose memory  
> management techniques are to crash when they aren't able to  
> allocate sufficient memory to cache new items.  Perhaps this will  
> finally kill off BINDv8?).

If an increase in cache requires even one or two orders of magnitude  
increase, there should also be equal concern about the relative  
amount of UDP traffic as well.  TCP is relatively reactive to  
congestion, but will be much less effective as a buffer when the UDP  
traffic increases substantially.  The DNS server rightfully do not  
care about congestion.  The client gets what's requested.  DNS  
certificates are more of an appropriate use issue than a protocol issue.

>   If there is wide scale deployment of this, caches in front of  
> mail servers (and other apps that make use of user keys) will  

When these applications need keys for both reading and writing are on  
the desktop, this will effectively burden the entire system with few  
options for isolating the problem to select servers.

> Perhaps an "Operational Considerations of User Keys in the DNS"  

Why not include an analysis within this draft?  This draft offers the  
potential for disrupting DNS.  It has added enough features to  
justify review prior to acceptance.

I have great respect for Paul, and even want to believe he may have  
solutions.  Forgive my doubts about the infinite capacity of DNS, or  
that caching offers no benefit.  There are hundreds of millions of  
corporate mailboxes, and perhaps billions of private mailboxes with  
messages being exchanged at tens of millions per minute.  When having  
a certificate becomes a new paradigm for exchange, there will be a  
fairly flat distribution of activity at every phase of email use.   
This live distribution of information could be problematic as well as  
a wasted expense.  Add in wildcards and DNSSEC, then this quadruples  
the related traffic that is never cached.   Add to this concern  
possible follow-on applications as DNSSEC and DNS certificates become  
a new currency for user interchange.

A key server using disk based caching seems like a _much_ better  
approach for user certificates.  This is not the proper approach for  
DNS however.  These are different problems and deserve different  
solutions.  Look at this carefully and recommend the appropriate use  
for this type of record.  I also think there is a cheaper alternative  
that uses the SSH opportunistic strategy where there is an opaque- 
identifier and a single domain signature.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Sep 2005 10:15:06 +0200

> packet size as indicated in this statement.  The data-gram limitation  

Thanks for spotting this.  I have changed the last sentence to:

      They SHOULD NOT be used where the DNS message would have fit in
      a 512 byte UDP packet.

Is that OK with you?

> draft very much adds to this concern.

Sure.  And I have no problem adding text to mention this potential
problem.  But I think your suggested text was biased and implied that
deploying this on a wide scale would be harmful.  I believe the
opposite would be true.  But let's try to move back to actually fixing
the document...

> section.  At least warn that this may cause foot damage. : )

...right.  So how about adding the following under "Performance
considerations"?

  <t>Deploying CERT RRs to support digitally signed e-mail change the
    access patterns of DNS lookups from per-domain to per-user.  If
    digitally signed e-mail, and a key/certificate lookup based on
    CERT RRs, is deployed on a wide scale, this may lead to an
    increase of DNS load.  Whether this load increase will be
    noticable is not known.</t>

Would that address your concerns?  Feel free to adapt and modify the
text, or even merge it with your proposal, then maybe we can get
something we both agree on.

Thanks,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Sep 2005 03:58:47 -0700

>       They SHOULD NOT be used where the DNS message would have fit in

The term packet is used in 10 locations in this draft where it confuses
message content with the physical packet.  These are not the same.  This
unfortunate terminology was added by this draft.  I suspect the prior
Performance Consideration section suffers from similar confusion.

Read RFC1035 4.2.1. UDP usage  & RFC879. 

| Messages carried by UDP are restricted to 512 bytes (not counting the
| IP or UDP headers).  Longer messages are truncated and the TC bit is 
| set in the header.

> something we both agree on.

There needs to be more information.

Do you want this to work with DNSSEC?

Do you want this to work with wildcards?

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Sep 2005 13:24:59 +0200

> | IP or UDP headers).  Longer messages are truncated and the TC bit is 

All occurrences of "packet" that I could find referred to "OpenPGP
packets", and that is terminology borrowed from RFC 2440.  However, in
the same paragraph as you identified above, it did use "packet type"
to refer to the CERT RR "type" field.  That was incorrect.  The new
paragraph reads:

    <t>The IPKIX, ISPKI and IPGP types indicate a URL which will serve
      the content that would have been in the "certificate, CRL or
      URL" field of the corresponding types; PKIX, SPKI or PGP,
      respectively.  The IPKIX, ISPKI and IPGP types are known as
      "indirect".  These types MUST be used when the content is too
      large to fit in the CERT RR, and MAY be used at the
      implementer's discretion.  They SHOULD NOT be used where the DNS
      message is 512 bytes or smaller, and could thus be expected to
      fit a UDP packet.</t>

Is this satisfactory to you?

Please point out the other occurrences you found.

> Do you want this to work with wildcards?

To make it possible for me to add more information, I need to
understand what problems you see with using CERT RR together with
DNSSEC or wildcards.  For me, there is no additional problematic
complexity in either case.  Maybe you could suggest text.

To answer the questions, yes, I see some potential in combining CERT
RR with DNSSEC.  I do not see any point in having a CERT RR at a
wildcard owner name, the semantics of that seem unclear.  But I also
do not see any need to forbid it, if someone will find it useful in
some scenario.

Thanks,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Sep 2005 22:00:57 -0700

On Sep 14, 2005, at 4:24 AM, Simon Josefsson wrote:

> The new paragraph reads:

This is better.  The size noted as including overhead in the  
Performance Consideration section could be seen as misleading as  
well.  Perhaps this was the message overhead and not the transport  
overhead.  This is not clear.

> do not see any need to forbid it, if someone will find it useful in

It takes very little effort to generate traffic using wildcards.   
DNSSEC makes dealing with wildcards even more problematic assuming  
there is a desire to obtain a valid signature and have something more  
secure than the IP address.  I will ignore black-holes lists as this  
represents a special case that can be localized.

I'll attempt to estimate the impact on DNS handling user-keys.  I am  
sure I will be corrected where needed.

About 25% of DNS lookups obtain no answer, and about 12% return an  
error.  Due to aggressive retries, the no answer category represent  
about half of the WAN DNS traffic.  The WAN DNS traffic is about 8%  
overall with about a 10% packet loss rate, perhaps due to server  
limitations. The distribution of A records narrowly benefits from  
caching across a large population of machines which often have short  
TTLs as a means for load balancing or mobility.  A third of these A  
record lookups are not repeated.   Of this DNS traffic, perhaps 8% is  
related to email.  MX and NS records may benefit from caching with  
adequate TTLs.  NS caching likely represents the most significant  
performance benefit.  From the WAN perspective, caching does not  
appear wildly successful, while caching still offers improved  
performance.

Assume there are 1 billion mailboxes distributed across 20 million  
reputable domains.  This provides an average of 50 mailboxes per  
domain.  There is a steep distribution profile where tens of millions  
of mailboxes may be found within a single domain.  Deployment using  
user certs in DNS (identifiers and public keys) could be dramatically  
swift from a percentage standpoint, with adoption by several of these  
larger domains.

While public key related protocols suggest certs should be retained,  
this then requires a provision for revocation.  When a large domain  
offers free mailboxes, a revocation list will likely necessitate  
frequent updates.  These updates must be timely or abuse signed by  
their certs will remain chronic.  A corporation will also desire  
rapid retraction of certs when an employee's laptop becomes  
compromised or something or someone runs afoul.  One strategy was to  
simply put an expiration on the signed message and assume the cert is  
not be compromised.  Even with this, the period of time needed to  
assure delivery still allows for a fair amount of abuse.  Another  
alternative would be to put a short TTL on the cert for a short  
retention in DNS.  By then not retaining the cert in the application  
deals with the revocation problem.

The payloads normally exchanged in DNS per email may then include a  
mailbox cert query when writing the message to enable privacy.  A key- 
id cert query by the MTA when verifying the signature would then be  
followed by a perhaps a mailbox cert query by the recipient or  
recipients at some later date.  The size of the response will be  
larger, as will the query compared to the other still required DNS  
exchanges for email.  Rather than a dozen or so bytes to cache  
results, there is now a need for perhaps 30 times that amount, or  
perhaps these certs are simply not cached at all.  After all, these  
large records will be more thinly dispersed than A records.

Assuming some caching still happens in the normal exchange, this new  
cert per user may perhaps double the email DNS payload per cert  
exchange and increase the 8% of DNS traffic associated with email.   
Assume the average number of recipients is 4 per session where the  
initial mailbox was encrypted for a timed or group functionary.  A  
cert is needed to encrypt at the sender, and then a key-id cert will  
be needed by the MDA to check the signer.  Perhaps the mailbox-cert  
will then be obtained by each recipient for 6 cert exchanges for a 12  
times increase in payload doubling DNS traffic.  Then consider  
DNSSEC.  This will roughly double this traffic again.  Now 16%  
becomes 32% of overall traffic.

I have not added the wildcards and DNSSEC. The concept expressed in  
MASS was to use wildcards to create separate certs using a hierarchy  
of message/mailbox as the cert owner, where the good messages and  
mailboxes are handled by a wildcard and the bad are assigned a  
specific cert.  This would mean that to use DNSSEC effectively, the  
actual wildcard record will require a subsequent query.  Of course  
there are also the cname records to translate between key-ids and  
mailbox-addresses.  The wildcard doubles the traffic for these certs  
where 32% becomes 40% where the cname perhaps adds still more.  This  
seems to be going from about 8% of the DNS traffic to nearly half the  
overall traffic for an application that previously required very little.

Assume there are 30 million messages being exchanged every minute to  
perhaps an average of 3 recipients per session that are not  
encrypted, but where 20% are signed.  The amount of additional  
traffic just this generates using wildcards and DNSSEC would be about  
10k per exchange or an additional network burden of about 1 gigabyte  
per second of double cryptography for these early adopters to handle.

My advice:

Remove any mention of wildcards except to say wildcards are is not  
recommended.  Suggest how these cert records could be handled by the  
application and the DNS cache.  Add some warning that their use on a  
per user basis may impact DNS performance with a reduction in cache  
effectiveness, together with reductions in server and network capacity.

-Doug

---

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

Douglas Otis <[email-masked]> writes:

> This is better.

Good.

> The size noted as including overhead in the Performance
> Consideration section could be seen as misleading as well.  Perhaps
> this was the message overhead and not the transport overhead.  This
> is not clear.

OLD:

   Current Domain Name System (DNS) implementations are optimized for
   small transfers, typically not more than 512 bytes including
   overhead.

NEW:

   The Domain Name System (DNS) protocol was designed for small
   transfers, typically below 512 bytes.

I think the reference to what "current" DNS implementations are
optimized for may be wrong.  Current implementations support EDNS.0
and DNSSEC, and must handle larger messages.  However, it is certainly
true that the DNS protocol was originally designed for small
transfers, and saying that should be harmless.

Do this change solve your problem?

> overall with about a 10% packet loss rate, perhaps due to server

Do you have a reference for these numbers?  Is there anything that
suggest the same would hold for CERT RRs?

> swift from a percentage standpoint, with adoption by several of these  

I don't think it is fair to use the current number of mailboxes as the
number of CERT RRs that will be used tomorrow.  Things will be
deployed incrementally, starting with a few RRs, then a couple of
hundred, and then gradually more and more.  If things break, the
experiment is aborted.  This is the same for all technical
advancements.  We can certainly warn about this potential problem, but
without solid evidence, I think we should be careful about including
speculation.

A more realistic number to use would be the number of digitally signed
or encrypted S/MIME and OpenPGP e-mail messages exchanged today, where
the user had to involve LDAP or HTTP to lookup a certificate.  I
believe this number is very small compared to all other traffic on the
Internet.  How often to you lookup a certificate from a remote
database?  Your colleges?  Your mom?  I do it perhaps once per week.

> deals with the revocation problem.

Further, CERT RRs may store OpenPGP revocation certificates.  They are
small, about 100 bytes, so querying for them would be quick.

> large records will be more thinly dispersed than A records.

The draft doesn't imply MTA's should lookup certificates nor verify
the signature.  I think you are jumping to conclusions here.  Today,
not even many MUAs are able to lookup certificates and verify
signatures.

> becomes 32% of overall traffic.

All these numbers assume many things that are not in the draft, and
that nobody has proposed to do.

> overall traffic for an application that previously required very little.

Is anyone deploying this?

> per second of double cryptography for these early adopters to handle.

Again, I think your numbers are way off.

> My advice:

Thanks for reaching a conclusion.

> recommended.

The document does not mention wildcards, except for Edward Lewis
statement that, if I understood him correctly, was added precisely to
warn MASS people about the problem with wildcards.  The text reads:

    if multiple
    labels are used when mapping from a CERT identifier to a domain
    name then care must be taken in understanding wildcard record
    synthesis.

Does this solve your problem?  Please suggest text if not.

> Suggest how these cert records could be handled by the application
> and the DNS cache.

I don't know how to translate this into anything that would go into
the document.  I don't think a DNS cache has to, or even should, treat
CERT RRs differently from any other data.  How applications handle
CERT RRs depend very much on the application, and is better of
profiled in separate documents.  Perhaps you could propose some text,
to allow me to see what you are thinking of.

> Add some warning that their use on a per user basis may impact DNS
> performance with a reduction in cache effectiveness, together with
> reductions in server and network capacity.

I slightly re-worded the earlier text I proposed:

  <t>Deploying CERT RRs to support digitally signed e-mail change the
    access patterns of DNS lookups from per-domain to per-user.  If
    digitally signed e-mail, and a key/certificate lookup based on
    CERT RRs, is deployed on a wide scale, this may lead to an
    increased DNS load, with potential performance and cache
    effectiveness consequencess.  Whether this load increase will be
    noticable or not is not known.</t>

Is this ok with you?

Thanks,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Sep 2005 21:52:53 -0700

>    transfers, typically below 512 bytes.

This looks better as well.

> suggest the same would hold for CERT RRs?

There was a DNS performance study looking at MIT in 2002.  This  
comment was not about CERT RR, but rather to agree with the view that  
from the WAN perspective, caching appears to be of little value.  It  
looks even worse from the root server perspective.  It still helps.  : )

> without solid evidence, I think we should be careful about including

You missed the point that I was attempting to make.  Adoption by many  
of the larger domains may create a rapid change in the baseline.  Do  
not depend upon only a few using this record.

> database?  Your colleges?  Your mom?  I do it perhaps once per week.

Again you are depending upon this not being adopted on a large  
scale.  I only hope you are right.  Once this is attempted where  
there are hundreds of millions of messages using certs, a leisurely  
pace of obtaining certs and checking for revocations will need to  
change rather substantially.

> small, about 100 bytes, so querying for them would be quick.

While a list of cert serial numbers may be small for some domains,  
this may not be the case where it is most needed.  This added record  
may grow to be very large as well.  Of course, this could use TCP  
fall-back or a redirection to a standard cert service.  This  
situation has made implementing revocation mechanisms questionable,  
and this takes away control from the sending domain.  The shear size  
of the data that needs to be copied to millions of places still  
represents a sizable task.  Shortening the duration of the record to  
keep the CRL within reason also means this information needs to be  
copied even more frequently.  At some point, it may be easier to just  
get the cert.

> not even many MUAs are able to lookup certificates and verify

That situation is changing very rapidly.

> that nobody has proposed to do.

What do you mean by things?

> Is anyone deploying this?

DomainKeys and DKIM could do this now.

> Again, I think your numbers are way off.

I was looking at a marketing study.  I was attempting to estimate the  
network impacts.

>     name then care must be taken in understanding wildcard record

This text seems to suggest that when wildcards are used to be  
careful.  Certs and DNSSEC will get ugly with wildcards.  Perhaps  
adding or replacing this sentence with:

It is not recommended that a CERT RR be published as a wildcard.

> to allow me to see what you are thinking of.

When CERT RRs are found to occupy too much cache, it may be required  
to limit the maximum TTL for this type of record.

>     noticable or not is not known.</t>

I would drop the last sentence.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Sep 2005 10:58:31 +0200

> looks even worse from the root server perspective.  It still helps.  : )

Thanks for the reference.

> not depend upon only a few using this record.

I don't.  But I simply don't see the same problems that you do when
many people would start to use it.  Distributing the certificates
through DNS is a small step compared to everything else that has to be
modified to support a e-mail PKI on a wide scale.  Thus fixing any
implementations problems in DNS servers that there may be (although I
am not aware of any problems affecting this, nor do I expect there to
be any) can be done without any rush.

If you only assume the infrastructure we have today, and throw numbers
at it that may hold in 10 years, then showing that things will break
is not difficult.  But it doesn't work like that.  The Internet evolve
and adapt to changing user habits.

Don't get me wrong, I see no problem warning about potential problems,
but we shouldn't recommend against exploring this technology further,
nor should these warnings imply that we know for sure that there will
be potential problems.

> copied even more frequently.  At some point, it may be easier to just  

OpenPGP revocation certificates doesn't work like you describe.  There
is no list of cert serial numbers.

It appears as if you are talking about X.509.  For X.509, there are
more efficient revocation checking methods than using CRLs, there is
OCSP and XKMS.

Still, if the CERT RR would be used to serve X.509 CRLs, it will be
done through the IPKIX type, because most CRLs become larger than 64kb
sooner or later.  And a IPKIX CERT RR would typically be below 100
bytes.  So I don't see a problem here either.

> That situation is changing very rapidly.

Yes, but I'm talking about this document.

> What do you mean by things?

Performing certificate lookups and verification inside MTAs nor MDA.

Eventually, a MUA may want to lookup the certificate and perform
verification.  But this is done on the user's request, and is
currently handled by LDAP or HTTP.  If DNS is used, the LDAP/HTTP
traffic would go away (including the DNS lookups resulting from the
LDAP/HTTP requests).  The total network impact is the same, or
actually lower because DNS is more efficient.  I don't see where the
problem is.

> DomainKeys and DKIM could do this now.

A lot of protocols could use CERT RRs for stupid things.  Maybe the
problem is with those protocols, and not the CERT RR itself.

> It is not recommended that a CERT RR be published as a wildcard.

I have problems agreeing with this.  I see no justification for
recommending against CERT RRs at wildcard names.  My reasons are as
follows.

If some application somewhere is designed so that it can utilize, for
a good purpose, CERT RR data placed at a wildcard owner name, then
that is justification enough to allow CERT RRs at wildcard names.  If
there are no such application, CERT RRs at wildcard names simply won't
be used, and there is no problem.  The protocol using CERT RRs at
wildcard names may not scale well, but on the other hand, it might
scale just fine.  That depends on the design and usage pattern.  In
any case, I believe that any problem is with that application, not
with the CERT RR per se.  Possibly the problem is with the wildcard
concept in DNS, there are similar concerns with wildcard names for
other RRs too (remember the '*.COM IN A' situation?).  Placing A RRs
at wildcard names is still permitted by the specification, but whether
people chose to do this in practice depend on other things.  I expect
the same will be true for CERT RRs.

Remember, the text says to be careful about wildcards.  That is
sufficient warning for me.

At this point, I would appreciate hearing input from others on whether
we should explicitly recommend against placing CERT RRs at wildcard
names or whether the current text above suggesting that care is in
order when wildcards is involved is sufficient.

> to limit the maximum TTL for this type of record.

DNS caches must be able to handle too much cached data, typically they
discard data that hasn't been used for a while.  Creating additional
administrator burdens to protect poor DNS cache implementations is the
wrong approach, in my opinion.

> I would drop the last sentence.

Without it, it is implied that we know for certain that there may be
potential performance and cache effectiveness consequences.  I don't
believe we know this.  Expressing these doubts is thus fair to the
reader.

Thanks,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Sep 2005 11:48:02 -0700

> be any) can be done without any rush.

Rather than 10 years, the time frame could be much less.  Consider  
deployment at the MTA rather than at the MUA.  There is potential for  
this being done at both locations.  When done at the MTA, changes can  
be far more rapid.

> is no list of cert serial numbers.

OpenPGP disperses revocation information and uses key finger-prints.   
This dispersal technique increases the overall size and number of  
exchanges to obtain the aggregate revocation information.  This  
operation is performed at some time-frame by every node holding an  
associated key.  What is a reasonable time-frame for key revocation?

> more efficient revocation checking methods than using CRLs, there is

Once a session is required to either of these servers, what is the  
point of also placing the cert information into DNS?  It seems  
revocation is an item often lacking with respect to compliance within  
a diverse deployment.  This goes back to the reasonable time-frame  
question.

> Yes, but I'm talking about this document.

Imagine the worst case and then consider what advice can lessen the  
potential for harm.  Looking at DKIM and imagining how this document  
could be applied does not see unreasonable.

> actually lower because DNS is more efficient.  I don't see where the

It depends upon how this information is deployed, how it is used, and  
the reaction time related to revocation.

> recommending against CERT RRs at wildcard names.

Wildcard records offer the possibility of unexpected names referring  
to the cert.  In addition, when DNSSEC is deployed, a wildcard  
requires extra steps to validate.  These extra steps may not be  
implemented properly and may create possible security issues.  It  
would seem a simple recommendation against the use of wildcards would  
be a stronger caution than saying be careful.  It would not be saying  
this MUST NOT be used as a wildcard.

> wrong approach, in my opinion.

The cache is within the recipient's domain where an inordinate size  
and number of user-certs could rapidly consume DNS cache.  This cache  
would be better reserved for other record types more critical to  
overall performance.  When this RR type is accommodated, there may be  
need to consider this MAX TTL provision.

> believe we know this.  Expressing these doubts is thus fair to the

You have already indicated this "may lead".  (consequencess should be  
consequences.)  You have already indicated the modeling for the use  
of this type of CERT RR is unknown and can be used in a highly  
variable fashion.  I see no problem erring on the side of caution,  
rather than reinforcing an inability to judge consequences.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 19 Sep 2005 12:23:51 +0200

I'm trying to wrap this up, so I'm not responding to most of your
e-mail that is not strictly related to modifying the document.

Douglas, have you seen the -06 version?  You can get it from:

<http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt>

It would be good if we could move back the discuss to whatever changes
to the document that you feel are needed.  Please review the new
document to see whether it address your concerns.  Several suggestions
from this thread has been incorporated.

Douglas Otis <[email-masked]> writes:

> In addition, when DNSSEC is deployed, a wildcard requires extra
> steps to validate.  These extra steps may not be implemented
> properly and may create possible security issues.

I strongly disagree with this view.  Wildcard handling must be
implemented correctly in a DNSSEC application.  DNSSEC is insecure if
wildcards aren't handled correctly.

> It would seem a simple recommendation against the use of wildcards
> would be a stronger caution than saying be careful.  It would not be
> saying this MUST NOT be used as a wildcard.

But the document do caution against using wildcards:

   Note that this section describes an application-based mapping from
   the name space used in a certificate to the name space used by DNS.
   The DNS does not infer any relationship amongst CERT resource records
   based on similarities or differences of the DNS owner name(s) of CERT
   resource records.  For example, if multiple labels are used when
   mapping from a CERT identifier to a domain name then care must be
   taken in understanding wildcard record synthesis.

I believe your concern here has been addressed.  Note that this
paragraph was added after the last call completed, to address another
last call comment.  If you'd like to see different wording, please
propose text.

> rather than reinforcing an inability to judge consequences.

If I drop that sentence, are you happy with the document?  I still
believe the paragraph without the last sentence paint the wrong
picture for the reader, but your argument here is convincing, and
because (sadly) nobody else has stepped into this discussion to give
more opinions on the matter, I can make this change if doing so will
move the document ahead.

Thanks,
Simon

---

From: Alex Bligh <[email-masked]>
Date: Mon, 19 Sep 2005 12:21:57 +0100

> wildcards aren't handled correctly.

I'd tend to agree with that. If people do not implement algorithms according
to the specifications, that isn't a security concern relating to the
specifications, merely concerns about deficient implementations thereof.

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Sep 2005 08:27:03 -0400

Potential rat hole...

>wildcards aren't handled correctly.

If any part of any system is improperly implemented, problems ensue. 
Wild cards aren't especially more complex.

>last call comment.  If you'd like to see different wording, please

I agree with Simon.  The "danger" is that an application may assume 
that the synthesized record's owner name matches the certificate's 
identifying information.  This danger is in the text Simon has 
already included.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Sep 2005 14:07:03 +0000

# Potential rat hole...

potential?

# >>  In addition, when DNSSEC is deployed, a wildcard requires extra steps to
# >>  validate.  These extra steps may not be implemented properly and may
# >>  create possible security issues.
# >
# > I strongly disagree with this view.  Wildcard handling must be implemented
# > correctly in a DNSSEC application.  DNSSEC is insecure if wildcards aren't
# > handled correctly.
# 
# If any part of any system is improperly implemented, problems ensue. Wild
# cards aren't especially more complex.

agreed in general, but as a specific example wildcards demonstrate the
likelihood that no matter how clear a specification is, implementors are
likely to get it wrong, and arguments will ensue as to interpretation.

if there's a way to turn this point into a document improvement, it's to
come up with some kind of objective complexity metric and state that when
complexity is higher, the text must be even clearer and better reviewed.

i just can't think of which document to improve in that way.  certainly
not the storing-certs draft, which is quite clear enough by this time.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Sep 2005 11:58:20 -0700

> wildcards aren't handled correctly.

RFC2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

Add in the Performance Consideration section:

# It is NOT RECOMMENDED that a CERT RR be published as a wildcard.

This is a clear statement that a wildcard requires a higher level of  
caution.  My initial concern was related to added checks.  There  
could be increased overhead and possible implementation exploits.   
Adding a caution that recommends against wildcards does not prevent  
the their use, but rather raises caution over their use.  This seems  
like a prudent caution, especially in light of some suggested uses.

>    taken in understanding wildcard record synthesis.

Read carefully and you will not find any caution made with respect to  
the use of a wildcard, but rather how the CERT name space may not be  
related to DNS owner names.  This includes mapping with CNAMEs.  In  
establishing the bridge from the purpose-based name to the content- 
based name, there is an added comment that cautions about weak  
relationships between the CERT name space and the name owner of the  
CERT, especially with multiple labels.  As part of this, a reference  
to a wildcard is made.  This says little about the use of the  
wildcard, but rather is about the nature of the relationship between  
the domain name the separate CERT name space.  If anything, this  
tangential reference seems to validate the use of the CERT wildcard  
and offers no specific caution.

>
> If I drop that sentence, are you happy with the document?

Yes.  Also add a caution against the use of the wildcard as described.

-Doug

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Sep 2005 15:56:31 -0400

At 11:58 -0700 9/19/05, Douglas Otis wrote:

>This is a clear statement that a wildcard requires a higher level of caution.

I believe this is a tempest in a teapot.  Wildcards are not 
dangerous, although they have been misunderstood and poorly 
considered in many RFCs over the past decade.  Hopefully the wcard 
draft will fix that.

>Read carefully and you will not find any caution made with respect to the use
>of a wildcard, but rather how the CERT name space may not be related to DNS
>owner names.

That's explicitly the intent.

An application should always be careful of the data it receives, 
making sure the data is appropriate to the question.

In this case, the application should not assume that the queried 
domain name is related to identifying information in the certificate. 
It is possible that the queried name bear no 1:1 mapping to the 
identity borne by the certificate.

Specifications ought to be clear and unambiguous, yet retaining as 
much flexibility as possible.  This is why I would recommend against 
tightening language on this topic.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Sep 2005 17:02:22 -0700

> considered in many RFCs over the past decade.  Hopefully the wcard  

The concern is not about use of wildcards in general, but rather  
specifically in the case of user CERT RRs.  With user CERT RRs,  
overhead and security is a greater concern.  This draft proposes  
multiple CERT RRs or CNAMEs be published per individual mailbox.  One  
suggested strategy on the MASS reflector was multiple labels with a  
wildcard to permit millions of default references to a "good" CERT,  
versus specific references to a "bad" CERT thereby avoiding CERT  
revocation.

Depending upon whether a specialized cache is used, this strategy  
could cause user CERT information to become a significant portion of  
network traffic.  A wildcard user CERT RR eases publication for  
hundreds of millions of mailboxes, but then adds a fair amount  
overhead and complexity, especially in conjunction with DNSSEC.  In  
general, the strategy should attempt to place burdens on the sender  
rather than on the receiver.

Simply not recommending a wildcard to publish user CERTs conveys a  
note of caution. This does not prevent use of wildcards, only that  
there are other considerations that should be made, such as looking  
for wcard draft.

-Doug

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 20 Sep 2005 09:53:17 +0200

Dear Colleagues,

I have the impression we are going around in circles and that we are  
not converging any further.

I'd like to ask if we can all consent with the document as is now  
(http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt).

- --Olaf (In capacity of "document shepherd" )

- -----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Sep 2005 13:56:29 +0000

# I'd like to ask if we can all consent with the document as is now
# (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt).

aye.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Sep 2005 13:51:15 +0100

> (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt).

Yes.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Sep 2005 10:21:35 -0700

On Sep 20, 2005, at 12:53 AM, Olaf M. Kolkman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Dear Colleagues,
>
> I have the impression we are going around in circles and that we  
> are not converging any further.
>

There are parameters wherein a user-CERT record should not be  
disruptive.  With most records defined for DNS, patterns of expected  
record use is not a concern.  When dealing with large records on a  
large scale also expected to provide authentication at the desktop,  
it would seem there is a requisite for greater caution than provided  
in this draft.  This could include specific suggestions on cache  
consumption, or perhaps wildcards owing to increased overhead and  
possible resulting name space weaknesses.

Derogatory expressions reflect confidence, but unfortunately are  
without substance.  As such, the cycling is from confidence to  
specific concerns.  It would seem these concerns regarding wide-scale  
deployment of user-CERTs should not be dismissed in this cavalier  
manner.  Within the thread of this conversation, there have been  
suggestions DNS has infinite capacity and does not rely upon cache  
for performance, to noting that some older versions may crash.

This issue involves understanding the name space, revocation  
mechanisms, query rates, and where records are ultimately cached.   
Although concerns could very well be misplaced, related questions  
were not answered in this thread, nor made clear in the draft.  I  
have no desire to distract from other valuable efforts.  I will leave  
the fitness of this draft be judged by others in the WG.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Sep 2005 22:15:48 +0200

> possible resulting name space weaknesses.

There is an entire section called "Performance Considerations".  It
state that an increase of DNS load may occur and that it may have
performance and cache effectiveness consequences, and further that
CERT RRs may change the access pattern of DNS.  We don't have hard
data to offer more specific suggestions or warnings at this point.
Exactly what more are looking for?

4.  Performance Considerations

   The Domain Name System (DNS) protocol was designed for small
   transfers, typically below 512 bytes.  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 extension fields and using short field values
   for necessary variable length fields.

   The RDATA field in the DNS protocol may only hold data of size 65535
   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
   more than 64kb of payload, even if the corresponding certificate or
   certificate revocation list is larger.  This document addresses this
   by defining "indirect" data types for each normal type.

   Deploying CERT RRs to support digitally signed e-mail change the
   access patterns of DNS lookups from per-domain to per-user.  If
   digitally signed e-mail, and a key/certificate lookup based on CERT
   RRs, is deployed on a wide scale, this may lead to an increased DNS
   load, with potential performance and cache effectiveness
   consequencess.  Whether this load increase will be noticable or not
   is not known.

> for performance, to noting that some older versions may crash.

I don't think anyone is dismissing the problems you are bringing up.
I believe the document discuss them.

The DNS clearly do not have infinite capacity.  I believe the finite
capacity is more than sufficient to handle CERT RRs.

To some extent the DNS depend on caching for performance.  There are
different opinions on how much caching improve performance.

Software defects should not prohibit progress, people should fix their
servers.  If something can crash old servers, it will do so
independently of whether this document is advanced or not.  Crashing
servers may negatively affect deployment of CERT RRs, but that is
"our" problem.

What I'm saying is: if CERT RRs doesn't work, CERT RRs won't be used.

> were not answered in this thread, nor made clear in the draft.

I think the performance survey you are looking for simply doesn't
exist.  I think it would be very valuable to have such a survey
available (and I'm available for hire as a consultant if anyone wishes
to pay me to work on it).  If that survey would exist, it could be
referenced in the document.  But now all we can do is hint about broad
potential problems, which is done.

> I have no desire to distract from other valuable efforts.  I will
> leave the fitness of this draft be judged by others in the WG.

I hope others will chime in with their opinions.  I'm open to adding
text to address this issue if there is consensus on a specific
proposal.

Thanks,
Simon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Sep 2005 15:40:33 -0700

> text to address this issue if there is consensus on a specific

I am pleased there is now a general caution added.  For the specific  
suggestions, there was not consensus in regard to possible maximal  
TTL parameters or recommending against using a user-CERT wildcard.   
Unfortunately, the antithetical argument seemed too expedient as a  
basis of note.  Nevertheless, several expressed a desire this draft  
move forward without further discussion.  I suspect this ends the  
discussion.

-Doug

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 30 Sep 2005 09:20:18 +0200

> (http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-06.txt).

After that version the IANA considerations section was improved by  
adding a reference field for the CERT types.

I plan to notify our ADs that the last-call issues have been  
addressed and that consensus has been reached on version -08 of the  
document  (while still in the queue it lives on Simons Site: http:// 
josefsson.org/rfc2538bis/ ). I'll do so early next week.

Thanks for your cooperation.

- --Olaf