Thanks for the response John, more below.
On 03/13/2016 08:10 AM, John C Klensin wrote:
Paul, Doug,
I want to respond to two issues/questions only right now and am
going to do so in two separate messages. Perhaps someone else
will get to the other questions before I do -- I think they have
been answered and explained several times already. This is
therefore message 1 of 2.
I don't know why we (that "email community") and you (Paul) are
having so much trouble communicating, but
Having read a bunch of the DANE archives today it does seem that there
is a problem in communication, but honestly it doesn't seem all that
one-sided. :)
--On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters
<paul(_at_)nohats(_dot_)ca> wrote:
...
However, the email community experts themselves have already
stated that finding an email server compliant to case 2 is a
theoretical exercise only.
I can't speak for others, but I certainly didn't say that.
The specs (and generally-accepted good practice) recommend using
prohibition, aliasing (of some flavor), or other mechanisms to
avoid making subtle distinctions in addresses that are likely to
be confusing to users and/or to stress expectations about human
memory and precision beyond reasonable limits. I would
certainly recommend that a final delivery system not provide a
mailbox named pauL(_at_)example(_dot_)com to a different recipient than a
mailbox named paul(_at_)example(_dot_)com. I am agnostic about whether
they should be the _same_ mailbox or associated with the same
key: some recipient might plausibly use an obscure form of an
address as a mail classification tool or as part of a very cheap
sender-checking model. Such models, whether done that way or by
subaddresses or the like, are surprisingly effective against
casual bulk attacks even if much less so against focused and
determined ones.
I'm perfectly willing to grant that some systems do this. Paul's hashing
scheme accounts for this, and CNAMEs can be used to handle any aliases
that are desired.
Further, I think that many of the critics of the draft are ignoring the
fact that in the overwhelming number of cases the sending user is going
to have an example of the receiving user's e-mail address, the most
likely case being that they are replying to a message they already have
in their MUA. Thus it's overwhelmingly likely that the sending user will
already have a representation of the receiving user's local part that
the receiving user considers to be canonical, and thus is likely to have
placed an OPENPGPKEY RR for.
The same thing could be said for other distinctions. For
example, joe(_dot_)bloggs(_at_)example(_dot_)com is a popular form for a
local-part and has been used on some systems for years. IIR,
there is even a standards-track spec that recommends it. I
would certainly not suggest that a system that uses that form
for local-parts also support separate mailboxes, assigned to
separate recipients, named like "joebloggs(_at_)example(_dot_)com".
Whether is it better to not support the latter at all, to make
it an alias for the joe(_dot_)bloggs(_at_)example(_dot_)com form, or to
algorithmically remove the special characters(s), possibly also
making joe+bloggs(_at_)example(_dot_)com point to the same mailbox, is a
matter of taste: the specs are (deliberately) mute on the
subject.
Agreed, see above.
[snip]
Now, having said all of that, I want to note that this has
little or nothing to do with the protocol requirements of
draft-ietf-dane-openpgpkey-08. At least as I read it, that I-D
simply applies a hash function to the mailbox name as given and
does not attempt to find "equivalent" or "canonical" names.
That means that the very worse case is a false negative about
finding a key. You want to experiment with that, fine -- I
won't lose any sleep over it.
Good to hear! :)
I do believe that, if that is the
protocol spec, there is a lot of surplus and confusing text in
the I-D that should just come out.
FWIW, I agree that the draft in its current state needs some tightening,
as it seems to have some leftover tidbits from previous versions. I also
think that the approach suggested is wrong, and would like to see a
parallel approach codified (which I will comment on further in another
message).
Doug