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 > > >
<<attachment: smime.p7s>>