[Top] [All Lists]

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

2015-09-17 00:56:26
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.

This draft mandates that the DNS publishes only a small handful of the
addreses that an SMTP server would accept.  RFC 5321 describes how
local-parts are interpreted, and this draft doesn't do what 5321 says.

J. Levine, [3] 20150909
- Says because of LHS issue, every variation "has to be" put into
 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.)

Same thing.

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.

Yes, but not the other way around.  Note my example of john+bank@example
which works in SMTP but not in this design.

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.

I suppose -- the partitioning for the DNS would be unrelated to the
one used for mail, so you'd need some sort of crossbar to get stuff
from the existing mail system into the DNS.  Since the mail system
can't use its existing partitions, it in effect has to publish names
into one big flat zone even if the implementation of that zone
partitions it somehow.

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.

Note comments by draft author and others saying they're going to do name
guessing regardless.

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.

Note that decades of attempts to do this have all failed, and nobody I
know who is familiar with commercial mail systems believes it is
feasible.  It is not an accident that RFC 5321 and predecessors do not
attempt to describe rewrite or canonicalization rules.


<Prev in Thread] Current Thread [Next in Thread>