In light of all of the discussion about how the LHS of email addresses are
normalized and encoded/hashed in order to be used to publish certificates and
keys via DANE records like SMIMEA and OPENPGPKEY we have put together an
approach that lets a zone owner signal the policy that is used for their domain
by adding a few keywords to the DMARC record.
The draft is at:
https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/
I also posted this in the DMARC and DANE lists, Kurt Andersen posed a few good
questions so I have included my answers here:
1. Although this proposal appears to be an MUA feature, it has meaningful
relevance to the typical transfer agent as well. If it is fair to summarize
DMARC as a means for reducing the delivery of forged email then this proposal
fits in nicely. If an MTA can determine for example that a domain enforces a
policy of signing all outbound messages (by the email sender, not using DKIM)
and can easily locate the sender’s signing key with an appropriate chain of
trust then the MTA can make a reliable decision about whether that email
originated from the sender’s domain. This “feels” very similar to the way we
use SPF and DKIM now.
2. Signaling mechanisms are most effective when they can leverage a
beachhead already established by a deployed technology. DMARC has a growing
deployed base with building momentum so it makes an attractive mechanism for
signaling.
If a domain originating email signals a policy that all outbound messages are
signed and the recipient is unable to validate that signature then the
recipient should do something interesting with the message. Bear in mind that
the domain originating the records will have published the keys using a DNSSEC
signed domain and will have published keys/certs for the users who originate
mail from the domain. There would need to be a DNS resolution failure in order
for a recipient to not be able to locate the key. Although there are currently
still some deficiencies in the DNSSEC deployment, the operational picture for
DNSSEC is continuing to improve. This proposal anticipates DNSSEC reaching
critical mass.
We welcome discussion about this approach.
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917
A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp