Subject: [ietf-smtp] using DMARC to signal policy for email canonicalization, signing and encryption

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 3 Feb 2016 14:00:33 +0000

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