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