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

[Brian Dickson <[e-mail]>]

Top-reply to raise (IMHO) a major issue:

This is not only a "publish vs discover" issue, it also is dangerously
close to the IDNA rat-hole.

I wasn't around when the latter came up, but I think DNSEXT dodged a bullet
very wisely, by making it the applications' responsibility to handle
any/all case folding beyond ASCII.

There are also scale issues, e.g. consider use cases where #users in a
domain vary in order of magnitude. What works for O(10e3) does not work for
O(10e6), and definitely does not work for O(10e9).

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.

I implore everyone to please consider the design:

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

Brian

P.S. For those not familiar with it: The IDNA rat-hole involves
case-folding of >2:1, as well as things like Greek language where there are
lots of rules governing variant code points depending on context
(first/last letter of a word). Putting that into DNS would have been an
absolute nightmare, and pushing back on that request was IMHO the right
thing to do.

On Wed, Feb 25, 2015 at 11:15 AM, Viktor Dukhovni <[e-mail]>
wrote:

> On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote:
>
> > On Wed, 25 Feb 2015, Viktor Dukhovni wrote:
> >
> > >Once the client is making two queries, why accept collisions?  Are
> > >we (after all these years) finally defining RFC-822/2822/5322 local
> > >parts to be case-insensitive?  (Price of progress and all that?)
> > >
> > >Is a CNAME per-user really a major burden?
> >
> > It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul
> > paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P
>
> One CNAME per case-insensitive name (if the preferred form is mixed
> or upper case).  Those other names you're mentioning if they all
> share the same underlying keys would be CNAMEs you'd have to create
> with or without my proposal for a mechanism to publish case-insensitive
> names.
>
> > The client needs smart logic anyway, and the client at least has a user
> > it can interact with. It can ask "A key for [e-mail] does not
> > exist but there is a key for [e-mail]".
>
> Why ask the user, when the server can just publish the fact that
> all upper/mixed-case veriants of "paul" are the same mailbox.
>
> > Needing to roll out between 2 and 4 different capitalizations for
> > different [Ff]irstname.[Ll]astname makes everything more errorprone
> > and the client still needs its logic and user interaction.
>
> The I don't how you get to "4".  You can publish exactly one owner
> for each case-insensitive "LocalPart", no CNAMEs required if you
> are willing to accept clients making two queries to find keys in
> your domain (space/time trade-off):
>
>         SHA2-224(localpart@lowercase) IN <RDATA>
>
> Optionally, for faster queries, if the mailbox has a preferred
> form:
>
>         SHA2-224(LocalPart)             IN <RDATA>
>         SHA2-224(localpart@lowercase)   IN CNAME SHA2-224(LocalPart)
>
> If there's also a "Local.Part" and "local.part" to go with it, that
> it is completely separate from my proposal which deals only with
> handling case-insensitive matching.  The overhead of supporting
> case-insensitive matching is at most a second (CNAME) record for
> each record that would be there in the absence of the proposal.
>
> --
>         Viktor.
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>