Summary of IETF LC for draft-ietf-dane-openpgpkey

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]