dane-openpgp 2nd LC resolution

[Stephen Farrell <[e-mail]>]

Hi all,

The 2nd IETF last call for this started on Feb 8th.
Thanks again for the lively discussion.

The tl;dr version is: once a revision addresses the
substantive issues raised as per below, taking into
account reactions to this summary, and we have a chance to
take a quick look at -08 (I'll extend the LC to the date
of the -08 version plus one week), then if no new
substantive issues arise, I think we have rough consensus
to go forward with this experiment (and others to come)
and let the IESG review the document.

Cheers,
S.

The substantive issues that arose in the 2nd last call
were:

1. The context of the experiment
2. Changes to the trust model
3. The local-part (lhs) issue and i18n

For each, I'll say where I conclude we've ended up and
recommend what to do for -08.

1. The context of the experiment
--------------------------------

I think part of the reason this one has been hard has been
a perception that we're developing the one true way to
retrieve key retrieval for e2e email security.  The
resolution here is to include text like that below in all
similar experiments.

"This specification is one experiment in improving access
to public keys for end-to-end email security. There are a
range of ways in which this can reasonably be done, for
OpenPGP or S/MIME, for example using the DNS, or SMTP, or
HTTP.  Proposals for each of these have been made with
various levels of support in terms of implementation and
deployment.  For each such experiment, specifications such
as this will enable experiments to be carried out that may
succeed or that may uncover technical or other impediments
to large- or small-scale deployments. The IETF encourages
those implementing and deploying such experiments to
publicly document their experiences so that future
specifications in this space can benefit."

2. Changes to trust model
-------------------------

John Levine noted a place where -07 seems to be saying a
bit too much:

" In sections 1 and 7, it claims that finding a key
through DNS lookup is not a substitute for web-of-trust
verification, which is fine.  But section 5.2 says that if
a domain publishes a key for an address that's
inconsistent with an existing key, verification of the key
is "treated as a failure."  It's unclear what the effect
is supposed to be, but considering the discussion of the
lost key problem, it appears that the intent is that the
sender would stop using the old key. "

I think the text is 5.2 is a little ambiguous so suggest
the change below, which clarifies that the failure is
in the confirmation step and that the resulting action
is dependent on local policy and is not being determined
by taking part in the experiment.

OLD:

Locally stored OpenPGP public keys are not automatically
refreshed.  If the owner of that key creates a new OpenPGP
public key, that owner is unable to securely notify all
users and applications that have its old OpenPGP public
key.  Applications and users can perform an OPENPGPKEY
lookup to confirm the locally stored OpenPGP public key is
still the correct key to use.  If the locally stored
OpenPGP public key is different from the DNSSEC validated
OpenPGP public key currently published in DNS, the
verification MUST be treated as a failure unless the
locally stored OpenPGP key signed the newly published
OpenPGP public key found in DNS.  An application that can
interact with the user MAY ask the user for guidance.  For
privacy reasons, an application MUST NOT attempt to lookup
an OpenPGP key from DNSSEC at every use of that key.

NEW:

Locally stored OpenPGP public keys are not automatically
refreshed.  If the owner of that key creates a new OpenPGP
public key, that owner is unable to securely notify all
users and applications that have its old OpenPGP public
key.  Applications and users can perform an OPENPGPKEY
lookup to confirm the locally stored OpenPGP public key is
still the correct key to use.  If the locally stored
OpenPGP public key is different from the DNSSEC validated
OpenPGP public key currently published in DNS, the
confirmation MUST be treated as a failure unless the
locally stored OpenPGP key signed the newly published
OpenPGP public key found in DNS.  An application that can
interact with the user MAY ask the user for guidance,
otherwise the application will have to apply local policy.
For privacy reasons, an application MUST NOT attempt to
lookup an OpenPGP key from DNSSEC at every use of that
key.

3. The local-part (lhs) issue and i18n
---------------------------------------

This has always been and will always be an issue for any
solution in this space. Absent changes to the mail
architecture, or major changes to email protocols and
deployment, it will always be an issue. And it's quite
related to the  "joe+ietf" kind of lhs too, which'd need
to be considered for a general solution to the problem.  I
conclude that the right thing here is to do experiments,
but for those to not try to solve the general issue, and
instead to define the limits within which the experiment
is to be done. In this case, I think the only tractable
thing is stick with the lhs handling in -07, to note that
implementations are in fact not quite doing that, and to
point to an existing well-thought out description of some
some of the issues. To that end I suggest renaming section
4 to become "Email address variants and
internationalisaion considerations." and adding the
following NEW text to the end of the section:

"Section 3 above defines how the local-part is used to
determine the location in which one looks for an
OPENPGPKEY record. Given the variety of local-parts seen
in email, designing a good experiment for this is difficult
as: a) some current implementations are known to lowercase
at least US-ASCII local-parts, b) we know from (many)
other situations that any strategy based on guessing and
making multiple DNS queries is not going to achieve
consensus for good reasons,  and c) the underlying issues
are just hard - see Section 10.1 of RFC 6530 for
discussion of just some of the issues that would need to
be tackled to fully address this problem.

However, while this specification is not the place to try
to address these issues with local-parts, doing so is also
not required to determine the outcome of this experiment.
If this experiment succeeds then further work on email
addresses with non-ASCII local-parts will be needed and
that would be better based on the findings from this
experiment, rather than doing nothing or starting this
experiment based on a speculative approach to what is a
very complex topic."


Misc comments
-------------

- There were also a bunch of nits noted in [1] that we
may as well fix in -08.

[1] https://mailarchive.ietf.org/arch/msg/ietf/7qqmoghCO_BfAt3YdRn81chn5Mc