Re: dane-openpgp 2nd LC resolution

[Stephen Farrell <[e-mail]>]

Hiya,

On 06/03/16 15:10, Stephen Farrell wrote:
> 
> 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.

Paul has now posted -08 (diff at [1]) so this mail is
to extend the IETF LC until March 15th.

Thanks,
S.

[1] https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-08

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