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

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 2 Feb 2016 23:56:52 +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/

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Feb 2016 16:51:42 -0800

On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <[email-masked]> wrote:

> . . .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/
>

Section 1.2 of your I-D says:

> The previous specification of DMARC is almost entirely relevant to the MTA
> and transparent to the end user.  The additions in this document are also
> relevant to the MUA. . .

I'm not sure that mixing the features to be used by the MUA into the MTA
oriented specs for DMARC makes sense. For instance what would a receiver be
expected to do if they attempted to lookup an encoded recipient and could
not find the cited record? Would you expect them to enforce a non-pass
policy against that message?

I think it would be more appropriate to communicate this information at a
distinct end service point in the DNS - for example _mailenc.<domain>
rather than overloading the DMARC semantics with something that only has a
peripheral relationship to message domain authentication. Your proposal
seems more in the vein of "Encryption-Based Message Authentication,
Reporting and Conformance".

--Kurt Andersen

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2016 01:36:48 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>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.
>

Since this is a a draft about mail operations, I would strongly
suggest that you post it to the ietf-smtp list, where people with
experience in nontrival mail systems hang out.

In particular, you might ask about "canonicalization policy of LHS
portions of email addresses", and to move things along, you might want
to review RFC 5321 and find a better term than LHS.

I also share Kurt's concern that it seems like a bad idea to mix
advice intended for MUAs with the existing DMARC advice which is
purely for MTAs.

R's,
John

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 3 Feb 2016 13:35:44 +0000

Thanks Kurt.  Let me see if I can articulate our reasons for proposing DMARC as the signaling mechanism more clearly.

  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.
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

From: "Kurt Andersen (b)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 2, 2016 at 7:51 PM
To: Wiley Glen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption

On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <[email-masked]<mailto:[email-masked]>> wrote:
. . .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.

Section 1.2 of your I-D says:
The previous specification of DMARC is almost entirely relevant to the MTA and transparent to the end user.  The additions in this document are also relevant to the MUA. . .

I'm not sure that mixing the features to be used by the MUA into the MTA oriented specs for DMARC makes sense. For instance what would a receiver be expected to do if they attempted to lookup an encoded recipient and could not find the cited record? Would you expect them to enforce a non-pass policy against that message?

I think it would be more appropriate to communicate this information at a distinct end service point in the DNS - for example _mailenc.<domain> rather than overloading the DMARC semantics with something that only has a peripheral relationship to message domain authentication. Your proposal seems more in the vein of "Encryption-Based Message Authentication, Reporting and Conformance".

--Kurt Andersen

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 3 Feb 2016 13:36:48 +0000

Thanks for taking the time to look at the draft John.  I¹ll post this to
the smtp list as well.

I just responded to Kurt¹s concerns and would like to hear your opinion on
the answers.
-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

On 2/2/16, 8:36 PM, "John Levine" <[email-masked]> wrote:

>>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

---

From: Brandon Long <[email-masked]>
Date: Wed, 3 Feb 2016 13:55:53 -0800

As far as adding S/MIME or SMIMEA as an authentication mechanism, ie to
make DMARC act on "SPF/DKIM/SMIME" authentication, then adding it to DMARC
makes sense.

To include other domain email information that is unrelated to the
underlying p=REJECT/QUARANTINE concept, doesn't make sense.

Brandon

On Wed, Feb 3, 2016 at 5:35 AM, Wiley, Glen <[email-masked]> wrote:

> Thanks Kurt.  Let me see if I can articulate our reasons for proposing
> DMARC as the signaling mechanism more clearly.
>
>
>    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.
> --
> Glen Wiley
> Principal Engineer
> Verisign, Inc.
> (571) 230-7917
>
> A5E5 E373 3C75 5B3E 2E24
> 6A0F DC65 2354 9946 C63A
>
> From: "Kurt Andersen (b)" <[email-masked]>
> To: Wiley Glen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>> The previous specification of DMARC is almost entirely relevant to the
>> MTA and transparent to the end user.  The additions in this document are
>> also relevant to the MUA. . .
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Franck Martin <[email-masked]>
Date: Wed, 3 Feb 2016 18:25:50 -0600 (CST)

Or TLS, plenty emails on our systems provide a client certificate to our servers. The domain in the CN= could be used for alignment. 

I don't know if this is useful, as usually the emails have SPF or DKIM, but I see a sizeable portion of emails with no SPF nor DKIM providing a client TLS certificate signed by a trusted CA, and and an equivalent portion with self signed certificates. 

Overall it would cut by about half the number of unauthenticated emails (the ones with no valid SPF nor valid DKIM) if I would count the client TLS certificate as an authentication. 

----- Original Message -----

From: "Brandon Long" <[email-masked]> 
To: "Glen Wiley" <[email-masked]> 
Cc: [email-masked], "Kurt Andersen (b)" <[email-masked]> 
Sent: Wednesday, February 3, 2016 1:55:53 PM 
Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption 

As far as adding S/MIME or SMIMEA as an authentication mechanism, ie to make DMARC act on "SPF/DKIM/SMIME" authentication, then adding it to DMARC makes sense. 

To include other domain email information that is unrelated to the underlying p=REJECT/QUARANTINE concept, doesn't make sense. 

Brandon 

On Wed, Feb 3, 2016 at 5:35 AM, Wiley, Glen < [email-masked] > wrote: 

A5E5 E373 3C75 5B3E 2E24 
6A0F DC65 2354 9946 C63A 

From: "Kurt Andersen (b)" < [email-masked] > 
Date: Tuesday, February 2, 2016 at 7:51 PM 
To: Wiley Glen < [email-masked] > 
Cc: " [email-masked] " < [email-masked] > 
Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption 

On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen < [email-masked] > wrote: 

<blockquote>

<blockquote>
</blockquote>

--Kurt Andersen 

</blockquote>

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 4 Feb 2016 11:38:59 +0900

Glen Wiley writes:

 > 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

This makes no sense to me.  DMARC by design expresses policies
centralized in the administrative domain (AD) for email, and it
efficiently centralizes implementation in the MTA.  On the other hand,
draft-ietf-dane-openpgpkey-07 clearly states that it will be used to
distributes keys (plural!) linked to individual email addresses.  I
see no reason why the "typical" organization won't choose to have
equally individualized policies, especially in light of the fact that
DMARC and its lower-level components of DKIM and SPF already cover the
generic aspect of AD policy (though they don't mention encryption).
draft-ietf-dane-smime-09 refers to this possibility indirectly by
mentioning that the "trust anchor" might usefully be wild-carded --
which implies that in some cases it would not be, ie, it would be
individualized.

On the other hand, draft-ietf-dane-openpgpkey-07 acknowledges that "It
is unclear if this RRtype will scale to some of the larger email
service deployments."  Given the success of DMARC in reducing the
effect if not the quantity of malicious mail, as a mail admin I would
be dubious about linking an experimental protocol which could
potentially involve a large burden on my DNS to DMARC.  I don't see
any way for anybody on the Internet to use DNSSEC for traditional
operations, but opt out of DANE extensions here.  I think it should be
added if you're going to have AD-level policy discovery: you should be
able to say "we sign our A records but please don't ask us for PGP
keys".

One thing that worries me is that individuals or departments smaller
than an AD may choose to PGP sign and distribute keys by one of the
already established channels.  The protocol values "required",
"optional", "forbidden" are not expressive enough for this, unless
there is coordination between the AD and the smaller units, and you
proliferate subdomains and corresponding _dmarc subdomains merely to
express policy.  AIUI avoiding that proliferation and making the
_dmarc result cacheable for whole ADs is considered an advantage of
the DMARC scheme.

As far as I can see the main advantage of this proposal vs. having a
separate _dane_name_policy subdomain is that you can register the new
tags in the DMARC registry rather than establish a separate one.  Are
there any advantages to DMARC participating sites that don't want to
participate in DANE?

I imagine that if the dane-openpgpkey and dane-smime proposals were
widely implemented, with policy records to match, information about
mail flows that disregard those policies and those that respect them
would be of value for reasons similar to the value of information
about DMARC alignment.  Have you given any consideration to
integration of reports of that information with the existing DMARC
reporting?