Hiya, Thanks all for the energetic last call. The tl;dr version is I've asked the authors/chairs to work on revisions as outlined below. Those will at least need another IETF LC. The longer version is below... and long;-) Cheers, S. I went through the last call mails. I tried to separate out each of the points raised and give my interpretation of where we're at for each. Those marked "*SF:" (and not just "SF:") are ones where I think the issue raised does warrant a change to the draft. There are enough of those that I think a revised I-D is needed, and when that is ready I'll do another IETF last call for those changes. I don't think this needs another WGLC though, as the changes are clarifications, moving security considerations from [OPENPGPKEY-USAGE] to here, or better describing the experiment. (If the authors/chairs/WG want to re-do a WGLC that'd be fine by me too.) Note that I am not addressing what I think is an underlying objection which I interpret as "this won't work and is hence a bad idea." I do think folks can validly propose an experiment like this for a feature (e2e email security) we've never managed to get deployed at scale. (By "like this" I mean something with lots of associated and non-crazy concerns.) Were it the case that running this experiment would break a bunch of things I would feel differently but I don't think that is the case. E. Taylor [1] 20150829 - supportive but raises upper/lower case issue, suggests to add a "MAY lowercase" SF: WG decided against correctly I think. E. Taylor [1] 20150829 - identified a bunch of typos *SF: Those ought be fixed. P. Spacek, [2] 20150903 - hashing not good enough for privacy, suggests salting. SF: response was that salt means an odd DNS transaction, which seems a valid response to me, also that hashing isn't meant to (and won't) get strong privacy, but still marginally preferred by WG to non hashed LHS. J. Levine, [3] 20150909 - scaling issues discussed in WG but not resolved *SF: true, we should state that that is a crucial part of the experiment. I mean we ought note that the scaling issues are not (yet) resolved, not that we ought block on resolving those. (As we don't know how to scale e2e email security IMO.) J. Levine, [3] 20150909 - LHS only to be interpreted by recipient MTA, claims that this draft breaks that SF: This draft explicitly repeats exactly the MUST NOT required. A claim that the choice to hash the LHS as it is breaks this SMTP protocol requirement seems wrong. J. Levine, [3] 20150909 - Says because of LHS issue, every variation "has to be" put into DNS. SF: I do not buy that argument. (I do not claim to know more about email, but the idea that email operators would have to populate the DNS with every possible option seems wrong.) J. Levine, [3] 20150909 - Say that most addresses that could work with SMTP will not be in the DNS, leading to possible or actual failures. *SF: That is worth including as a consequence of this design. Presumably though, if all this is working, all the addresses that will end up used for PGP will also work in SMTP. J. Levine, [3] 20150909 - "Hashed names require that all of the keys for a domain be served in one flat zone. Large mail systems typically partition the users based on the local part, but since the hashes aren't reversible, there's no way to tell what partition would handle what hashed name." In a later [5] mail V. Dukhovni noted: "What does change is that the partitions responsible for user addresses would need to publish hashes to the corresponding server for the hash in question." *SF: I think that is correct and ought be stated as a consequence of this design. J. Levine, [3] 20150909 - "PGP key records are about 3K" and so should note the impact of this on zonefile size. *SF: I think that's correct, and ought be noted. Just adding any RR per mailbox would have an impact, but a KB or so per mailbox does make that notably worse. J. Levine, [3] 20150909 - "this draft pretty much demands name guessing." SF: I don't accept that and the draft says to not do that. It might be worth noting as part of the experiment that recording if implementations do/don't guess would be good. J. Levine, [4] 20150910 (in follow up to authors) - Suggestion to publish re-write rules as a domain specific thing in the DNS (maybe with a registry of standard rules) SF: Seems like it could be done. If this experiment was a success in getting deployment that should help too. But that could be done later. S. Josefsson, [6] 20150910 - Mention the relationship with RFC4398 and why that approach was not taken. *SF: I think if any other change is made the explanation for this difference is worth adding as it was brought up a number of times and is non-obvious. (Since I am asking for other changes, I've also marked this with a '*'.) J. Klensin, [7], 20150911 - Suggests that noting the divergence from 4398 is not enough but that this draft needs to be " proposing to update or depreciate the earlier spec" SF: I don't think that is a reasonable expectation for an experiment. Maybe we don't yet know how best to deprecate. J. Klensin, [7], 20150911 - This draft doesn't follow the web of trust. SF: Neither do OpenPGP RFCs, that's one possible deployment. J. Klensin, [7], 20150911 - "The conditions of the experiment need to be laid out, including how the experiment is going to be evaluated and when" SF: I think more description of the experimental nature of this spec would be useful, but that insisting on how the experiment would be evaluated and when, while nice, ought not be required in an experimental RFC. J. Klensin, [7], 20150911 - [OPENPGPKEY-USAGE] needs to be normative. *SF: I think informative references to descriptive material is fine. Presumably the WG may gain more knowledge of usage as the experiment proceeds and the end result will be better if the usage document follows later. However, I think John is correct in that there are some things in [OPENPGPKEY-USAGE] that need to be in here, e.g. the MUST NOT in 4.4 really ought be here. So it would make sense to move any security considerations text about which we're now confident from [OPENPGPKEY-USAGE] to here, including I guess all 2119 MUST-level conditions that would apply to implementations of this. J. Klensin, [7], 20150911 - "The Introduction to the I-D should be rewritten to explain why this is being done and what problem it solves." SF: I think both are clear enough already in the current text for any reader who cares to implement or experiment with this and who has the requisite skills/knowledge to do that. [1] https://mailarchive.ietf.org/arch/msg/ietf/5uuauzlKTL_OJenfOHXHElF2Ia8 [2] https://mailarchive.ietf.org/arch/msg/ietf/6TmgAvww0wBOQJ4MTIyB3PO80q4 [3] https://mailarchive.ietf.org/arch/msg/ietf/_kUe6YG6BUMlI43I65okFhqR6L8 [4] https://mailarchive.ietf.org/arch/msg/ietf/_Fsbt4zxIZO6j_Z9DTW00elkqqE [5] https://mailarchive.ietf.org/arch/msg/ietf/ZWqkTsa2yXsB9SIlkHIWUkwYNgQ [6] https://mailarchive.ietf.org/arch/msg/ietf/TfRrOlvpislNQQPePY8N5wA6ZM4 [7] https://mailarchive.ietf.org/arch/msg/ietf/kqJmGNzfTJNhr3wXEQZuG-6k9ZE