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