On Fri, Sep 11, 2015 at 02:43:59AM -0400, John C Klensin wrote:
(2) If the use of this approach leads to violations of 5321 (as
both John L. and I believe it does) or could have other side
effects on the use and operation of the mail system, then the
I-D should have an evaluation of those cases and bow any damage
can be mitigated both during the experiment and in any possible
production follow-up. If the WG expects the latter to emerge
during the experimental period, that should be explicit and the
experimental evaluation should conclude the effort was a failure
if that does not occur.
Note, I am ambivalent as to whether the draft represents a sound
long-term approach to publishing user keys in DNS.
However, I should note that I take 5321 to apply primarily once
messages enter the email transport system. At the point of message
composition, when a user is interactively composing an email, if
the MUA allows the user to try a case invariant of the address
(particularly on devices that gratuitously capitalize the first
letter of entered text) that I think is outside the scope of 5321
which keeps relays from damaging messages already in transit.
Trying a lower-case variant is something an MUA supporting the
draft would do to help a user find the right key. This does not
introduce damage of message envelopes for mail in transit.
So I think the main objection is not that a variant (lower-case)
might be tried, but that there's no way to find all the right
variants to try (e.g. +extensions, especially since even the "+"
is a destination-dependent character). This means that a user who
wants to receive end-to-end encrypted email for a set of distinct
addresses that are all mapped to the same mailbox would need to
publish multiple public key bindings.
One might note that with both PGP and S/MIME, the public key binding
is via a "certificate" that also includes the user's address.
Implementing MUAs would then be expected to adapt their address to
key binding logic when they implement support for obtaining keys
via DNSSEC, by creating a binding from the lookup key to the result
at the time the key is retrieved, that overrides addresses found
in the "certificate", since absent other trusted evidence in the
retrieved "certificate" any other addresses found with the key are
not trustworthy. Therefore, "certificates" obtained from DNS cannot
simply be merged into an existing "public keyring", they have
different naming semantics.
(5) The Introduction to the I-D should be rewritten to explain
why this is being done and what problem it solves, noting that
the problems associated with the ability to store a bogus
(unsigned/ unverified) key on a keyserver is merely replaced in
this proposal by the ability to store bogus keys in the DNS that
are no better linked to the user's web of trust than those
unsigned keys on keyservers (btw, "in-person" has nothing to do
with it -- the issue has to do with whether the key contains
enough information linked to the web of trust of the relying
users to be meaningful, so the I-D is also slightly misleading).
Whether an MUA is willing to employ the PGP message format for a
different trust model (not web of trust, but DNSSEC-validating
domain operator assertions) is up to the user of the MUA. I don't
think it is fair to accuse this draft of violating web of trust
(WoT), the PGP message format is not irrevocably tied to WoT.
If the user and MUA want to be able to employ DNSSEC to obtain keys
for correspondents well outside their social circle, it is not
reasonable to call these keys "bogus". They are certainly less
"bogus" than most web site (DV) certificates.
We've long ago learned that scaling secure communications to the
masses means giving up absolute end-to-end assurance. Usable
encryption for the masses will not be as strong as tailor-made
encryption for covert agents.
I don't know that this particular design (or in fact any design)
will bring secure end-to-end email to the masses. The masses might
in practice find encrypted email much to painful to use (unlike
ephemeral communication, people often want to retain and later
search their past email communications, and end-to-end encryption
makes that substantially more difficult).
This could make scaling less of an issue, because adoption rates
are likely to be rather low, I don't expect any large provider to
enroll all but a tiny fraction of their users in the foreseeable
future.
I am not vigorously endorsing this draft (damning with faint
praise?), but I do want to clarify some of the issues as I see
them.
--
Viktor.