Preface: I've been working on this note intermittently for a few
days. I think I've eliminated inconsistencies that arose during
that process, but please forgive me if not.
It seems to me that there are two major clusters of issues with
this spec. One set have to do with interactions with earlier,
standards-track, models for storing keys or certificates in the
DNS. Simon and Bill have addressed that and I assume can be
counted upon to continue to do so if needed. I do believe,
however, that a proposed Experimental spec should not be
proposing to do something that overlaps heavily with the goals
of a standards track spec, yet does things differently, without
commenting on, and proposing to update or depreciate the earlier
spec. Note in a mail message that say, essentially, "we talked
about that and decided the old spec was a bad idea" do not seem
to me to be sufficient for that purpose.
The second relates to interactions with the email environment
and DNS scaling, especially the relationship between whatever is
used as a DNS lookup key and the email address. Those seems to
be the main theme of John Levine's remarks and are the topics I
want to address.
--On Wednesday, September 09, 2015 16:49 -0400 "John R. Levine"
<johnl(_at_)iecc(_dot_)com> wrote:
- 'Using DANE to Associate OpenPGP public keys with email
addresses' <draft-ietf-dane-openpgpkey-05.txt> as Proposed
Standard
This draft has several technical issues that will make it a
problem to interoperate at Internet scale. They've all come
up in the WG mailing list, but they're still unresolved.
It would be great if there were a workable automated way to
discover an encryption key for an address. I'd like to sign
up on my bank's web site with the tagged address
john+bank(_at_)example(_dot_)com, the bank's then automatically looks up
the key (likely the same as for john(_at_)example(_dot_)com,) and after
that the mail they send to me is encrypted to my key, and they
can verify that the mail I send to them is signed with my key.
...
In part because John L.'s comments are the only ones posted so
far in opposition to approving this draft because of email
issues, let me add a few remarks and emphasize a few points.
First, I agree with his analysis (all of it, not just the
introduction quoted above).
In particular and from my point of view (RFC 5321 editor hat
very much on), SMTP-transported email has become ubiquitous
throughout the network-connected world precisely because it was
designed, and has evolved further, to provide adequate support
of a variety of implementation and operational models. In
particular, it works when the SMTP servers involved are
relatively small, serving only a single household or SME; it
works with very large and centralized email providers, including
those who handle many messages that never leave their own
systems (and hence might be considered equivalent to the
non-network centralized mail systems of the 70s and 80s); it
works in both single-hop and multiple relay situations,
including those that involve gateways to non-SMTP and even
non-Internet environments; it works in both message delivery
environments and "notify and pick up" ones; it works and is used
for control messages and signaling as well as human-human
communications; and so on. Some of the provisions of RFC 5321
to which John Levine refers, including the prohibitions on
interpretation of local parts anywhere in the path before the
delivery server (the prohibition that effectively prohibits
guessing), are not merely historical artifacts but have proven
key to supporting those alternate models, including links to
alternate email systems and scenarios over which the IETF has no
control.
"This won't screw up a very large percentage of users or their
email addresses" is not an adequate story if what is being
discarded is one of those models. Again, if mail service other
than to users of GooHooSoftMail were simply discontinued, the
percentages would not be large, but the damage to the Internet
would be considerable. And, if an extension is not accessible
except to, e.g., YaMicOgleMail users, it is not something the
IETF should be entertaining.
In the hope of heading off a side-argument, if we were to decide
that one of those models was the only important one, we could
design protocols that would be much nicer than SMTP. However,
at least so far and despite several proposals, the IETF and the
broader community have rejected all of those "we only need one
model" approaches. We should not allow one of them to sneak in
through a back door in an experimental spec either.
Despite that, we've seen an increasing tendency in recent years
to come up with, and even standardize, approaches that work well
for one particular model, more or less with the assumption that
everyone can either switch to that model or that whatever bad
effects happen are the fault of the non-switchers. That seems
undesirable to me, even with a nominally "experimental" protocol.
I don't think it has been mentioned in earlier messages, but
what is perhaps the most fundamental design characteristic of
PGP -- the Web of Trust idea -- is violated every time someone
picks up a key from a keyserver and trusts it based on where it
was found. As far as I can tell from the Introduction to this
spec, the main objection to the use of keyservers is that they
can contain invalid or faked keys. If so, the motivation is
very weak indeed because (i) The problem could be more easily
solved by adding provisions to keyserver protocols that would
warn or restrict retrieval of unsigned keys or even keys that
are not anchored in the retrieving user's web of trust and (ii)
to the extent to which this design depends on name- (or
address-) guessing, incorrect guesses are possible. If the keys
are important and validated by their presence in the DNS, the
possibility of bad guesses creates an business opportunity for
bad actors abetted by unscrupulous registrars (the presence of
unscrupulous DNS registrars on the Internet has been extensively
demonstrated). This problem is essentially confirmed in the
third paragraph of Section 7.4 of the I-D. So the very
justification given for this protocol is dubious... and
"Security is provided via DNSSEC" comes very close to the
spreading of low-quality, or even imitation, pixie dust.
Recommendations:
(1) Particularly because it has the potential for weakening
interoperability in the installed base, if this is going to be
an experimental protocol, then the conditions for the experiment
need to be laid out, including how the experiment is going to be
evaluated and when.
(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.
(3) John's concerns about DNS scaling are clearly as important
as mine about ill-effects on email infrastructure and
operations. I suggest that this draft be referred to DNSOps and
the IETF Last Call and its evaluation be suspended until there
is consensus in that WG that this is safe and would be safe at
scale, even as an experiment.
(4) The IETF normally requires that specifications contain
Security Considerations sections and that they be meaningful and
substantive. The one in this document is dependent on a
reference to an Internet Draft. That draft is listed as
Informative but, given the statement "OPENPGPKEY usage
considerations are published in [OPENPGPKEY-USAGE]." the
reference is a requirement for understanding the security issues
with the proposal and is hence normative. Similarly, "See
[OPENPGPKEY-USAGE] for more in-depth information on safe usage
of OPENPGPKEY based OpenPGP keys" in Section 7.4 is
unquestionably a normative reference as well as indicating that
the text that is redundant with that in
draft-ietf-dane-openpgpkey-usage-01 is not a replacement for it.
Worse, the referenced I-D does not exist: that draft expired
last April and, if "expired" is to mean anything, it cannot be
cited as even active work in progress. This issue should have
been caught and dealt with by the WG or, if not, by the relevant
Shepherd or AD. The Last Call should be suspended or abandoned
and the document returned to the WG until the document is
revised to contain a Security Considerations section that is
either complete and self-contained or that uses normative
references to active documents that are expected to be published
as RFCs soon enough to be meaningful.
(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).
This I-D is just not ready for prime time, even as an
Experimental specification.
john