Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

[Brian Dickson <[e-mail]>]

On Wed, Feb 25, 2015 at 4:31 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Wed, Feb 25, 2015 at 01:41:19PM -0800, Brian Dickson wrote:
>
> > There are implications to DNS resolution & caching, if you consider stub,
> > recursive, and authoritative actors. It may be the case that multiple
> > queries need to be done by the stub, regardless of approach. However, if
> > policy discovery involves looking up a single common record per DNS zone
> > (e.g. rhs of email address), then this is cacheable and reduces both the
> > size of the publishing zone, as well as the number of queries by the
> > recursive to the authoritative, per client query.
>


>
> However, this does not substantively impact the scalability of DNS
> caching, by which I mean that the number of cache entries is
> increased by a factor of two rather than some much larger factor.
>

For all but the most unusual domains, I would expect the user queries to be
all long-tail, with no substantial busy user set.

So, the caching of the policy record improves client query count (1 vs 2),
times total volume to the zone.

I would even expect that individual user entries to have TTL = 0, as there
is little to no value in caching individual records.
(Stubs might briefly cache, as might MTAs, but that is at the app layer,
not the DNS resolver.)

The real problem is the number of entries required in the zone. (see below)


>
> > _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish
> > all the case-folding rules for the zone, and require the client to use
> this
> > to discover the canonical (published) owner name for a given email
> address.
>
> This complicates the client code, but avoids the factor of two in
> the number of cached records.
>
>
To use the gmail example, I just did a test.

I was previously unaware of the "s/\.//g" behavior. But, it is real.

So, I sent mail to a never-before-used variant of my name, "br.i.an"
instead of "brian".
Lo and behold, it was delivered to my mailbox.

If the goal was to preserve this behavior, while having MUAs look up keys,
without a policy mechanism, it would be necessary to publish 2^(N-1)
records for every name of length N.

If the average length of a name were 11 characters, then 2^10 = 1024
records would be needed per user.
This takes O(10e9) and turns it into O(10e12), of thing which have to be
hashed, signed, and then NSEC/NSEC3-ified.

So, the publishing side takes a disproportionate hit.

Have the client understand a very limited set of case-folding rules, which
could be used universally, is clearly preferable, even to the client, IMHO.

Brian