On Tue, 9 Jun 2015, Peter van Dijk wrote:
Even experimental seems a bit strong for a lookup method that has seen so
much debate without serious improvement.
Actually, the improvement has been to no longer require multiple records
to support Uppercase'ed email addresses often accidentally created on
virtual keyboard devices. This change came after a lot of discussion on
the list and in person at the last IETF, both in the dane meeting and
outside of it. It seemed (to me) the consensus was that the lookup
problem was a separate problem that could be solved by SMTP protocol
extensions, but that such extension should not be defined by this
document.
The hashing method is poorly specified, and stronger text would not help
I think you actually mean to say you do not like the hashing method. The
specification itself is very carefully and clearly specified. If you
feel it is poorly written down to its intend, please supply a suggested
text change for us to consider.
- we are still preventing lookups
in case of lower/uppercase differences
Some of the SMTP/Email folks said themselves that case sensitive mailboxes
do not exist in real life, only in historic RFC specifications. To
complain about not supporting PAUL being different from paul is not very
different from not supporting UUCP !bang addresses, which are technically
still valid email address formats.
The confusion that [email protected] is not [email protected] is in itself
a problem much larger than not finding the 'right' crypto key for
[email protected]
, subadresses (peter+foo)
Nothing prevents you from adding an OPENPGPKEY for hash(lower("peter+foo"))
You are prevented from making things up on the fly without backing up
the thing you just made up. Well, what would people do when they see
[email protected] leading to a PGP key which only has
[email protected] on it? How can I know those are not actually two
different peter's? Supporting +wildcarding just moves the problem.
, dot > insertion (gmail).
Nothing prevents you from adding an OPENPGPKEY for
hash(lower("[email protected]))
You are again prevented from making things up on the fly without
backing up the thing you just made up. It relies on humans making
a decision that there probably are not two peter's at powerdns.com,
assumptions that cannot be made for email domains like gmail or yahoo.
Let me emphasize that: the draft is, in its current form, undeployable for
Google Mail.
I fail to see that. What I see is that mailbox auto expansion has a
problem very similar to the public suffix problem. It depends on human
knowledge that is not made available reliable for automated tools.
Still, google could add openpgpkey records based on the rewrite rules
only they and their customers know about.
Better methods than hashing have been proposed. For example, split base32 is
better in every way
Can you explain that, because I do not see that.
Let's say we would use chopped up base32 without lowercase without
hash. How would Google Mail be able to support [email protected]
or [email protected] better? They still need to either get from you
a list of permutations to generate many records, or you still have to
have logic on the client stripping out things sending multiple queries,
and then it won't matter whether the attempts are for hashed or split
base32. How would clients know that peter+foo is or is not the same
mailbox as peter?
The problem is the sender using made up things and forcing the receiver
to depend on a human to determine that some local part is or is not, the
same person. This draft does not pretend that problem is solvable.
(and, as a bonus, actually deployable, unlike the hashing
method)
Odd statement, as fedoraproject.org and mail.de have deployed this.
Moving the draft forward in its current form, onto Standards Track, would be
a mistake. Moving it forward as Experimental would be somewhat better, but I
suggest using even stronger language explaining that this RFC only defines an
RRtype, keeping the lookup mechanism as no more than a weak suggestion.
That would be a terrible solution and reduce one of the key features
this draft solves - key discovery. It would also lead to interop
failures of developers who have "implemented" the document yet only
implemented it partially.
- section 5: is "recommended" there meant as a 2119
thing? If so, it's usually better in uppercase.
The mention of TCP here, as in 6.1, is a weird operational sidestep for this
document. DNS operators know about big records and responses, and can deal
with them accordingly, without singling out specific RRtypes.
Unforutnately, most DNS amplification attacks are not the fault of DNS
operators who know what they are doing, and having an RFC reference to
point out broken and unwise behaviour makes it much easier to patch
broken implementations. I talked to various people about how much I
should put in, for example there are also issues about cache size and
using openpgpkey records to cause other records to be removed from the
cache, and especially after talking to Mark Andrews and Andrew Sullivan
it was clear that those considerations did not belong in this document.
If we have a better and generic RFC that goes in depth to the operational
issues of amplification and DDOS attacks, I could reference that document
instead. Unfortunately, I do not think such a document exist.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
