Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt

From: [email-masked]
Date: Mon, 17 Aug 2015 19:09:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF.

        Title           : Interoperability Issues Between DMARC and Indirect Email Flows
        Authors         : Franck Martin
                          Eliot Lear
                          Tim Draegen
                          Elizabeth Zwicky
                          Kurt Andersen
	Filename        : draft-ietf-dmarc-interoperability-05.txt
	Pages           : 22
	Date            : 2015-08-17

Abstract:
   DMARC introduces a mechanism for expressing domain-level policies and
   preferences for email message validation, disposition, and reporting.
   The DMARC mechanism can encounter interoperability issues when
   messages do not flow directly from the author's administrative domain
   to the final recipients.  Collectively these email flows are referred
   to as indirect email flows.  This document describes interoperability
   issues between DMARC and indirect email flows.  Possible methods for
   addressing interoperability issues are presented.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 21 Aug 2015 17:07:03 -0400

On Monday, August 17, 2015 07:09:02 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance Working Group of the IETF.
...
Comments:

Page 3, Section 1, para 3:

"... rejection policies on email flows can be significant ..."

I think this should read:

"... rejection policies on indirect email flows can be significant ..."

otherwise it makes no sense in this paragraph.

Page 4, Section 2.1, para 5:

Recommend replace this text:

   SPF can provide two Authenticated Identifiers.  The first one is the
   RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO.  The second
   one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
   [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
   in the case of "bounce" messages, on the domain found in the HELO/
   EHLO SMTP command.  DMARC uses only the SPF results for the
   RFC7208.MAILFROM identifier for alignment (this is often true for
   local policies outside of DMARC as well).

With:

   The DMARC relevant Authenticated Identifiers that SPF provides is the
   RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
   [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
   in the case of "bounce" messages, on the domain found in the HELO/
   EHLO SMTP command.

I think it better keeps the focus on what's relevant to DMARC and is clearer.

Regarding the last sentence of the paragraph, I would strike it.  I'm not 
aware of anything would be particularly relevant to DMARC nor have I heard 
anything about issues caused by SPF libraries that haven't been updated.

Page 6, section 2.2, second bullet point:

SPF may pass/SPF might pass

final paragraph:

DKIM must be/DKIM will be

Page 6, section 2.3, paragraph 2.

The length tag is, as far as I know, unused.  I would propose replacing the 
paragraph:

   Although DKIM provides a length flag so that, in theory, content can be
   appended without invalidating the signature, in practice, the length flag is
   seldom used due to security issues (see Section 8.2 of [RFC6376] for
   additional security considerations).

While I agree we ought to mention this for completeness, let's make it clear 
that's all we're doing.

Page 10, section 3.2.2, para 2:

I think this paragraph is written backwards:

   ReSenders introduce DMARC interoperability issues as content
   modification invalidates DKIM signatures.  SPF's ability to grant
   authorization via alignment is removed as the new Recipient receives
   the message from the Mediator rather than the initial organization.

ReSenders haven't introduced any interoperability issues.  DMARC has.  How 
about:

   The DMARC design does not cope with common ReSender functionality
   such as content modifications that invalidate DKIM signatures and Mail From
   rewriting to support SPF authentication of resent mail when the new
   Recipient receives the message from the Mediator rather than the initial
   organization.

Page 15 section 4.1.1.1, bullet 4:

   o  MTAs sending email on behalf of multiple domains may require
      Domain Owners to provide DKIM keys to use DKIM to avoid SPF
      alignment issues.  Managing DKIM keys with a third party has
      security risks which should be carefully managed.

This can generally be done through CNAMES or subdomain delegation.  I've yet 
to see anyone handle this situation by actually exchanging private keys across 
an administrative boundry.  I think it's worth discussion (so I don't proppose 
text) since others may have different experiences.

Page 16, section 4.1.3.1, para 2:

   A first option is to use the Original-From [RFC5703] (or X-Original-
   From) header field for this purpose in various contexts (X- header
   fields name are discouraged by [RFC6648]).  However, handling of
   Original-From (or X-Original-From) is not defined anywhere.  It is
   not currently used consistently or displayed to the user, and in any
   situation where it is used, it is a new unauthenticated identifier
   available for exploitation unless included within the scope of the
   new DKIM signature(s).

Let's kill the bits about X-.  We're past the third anniversary of the RFC 
that suggests it's a bad idea.  I think Original-From is fine, but if people 
don't want to reuse that, then come up with something more descriptive than 
X-.

Page 19, Section 6:

In 4.1.3.3 where it discusses header rewriting, it mentions that this might 
undermine the effectiveness of DMARC.  I think that qualifies as a security 
consideration that should be addressed (even if only by moving most of the 
existing text here with a pointer).

Hope that helps,

Scott K

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2015 22:48:34 -0000

>ReSenders haven't introduced any interoperability issues.  DMARC has.  How 

Indeed.  I agree with the advice to refrain from blaming the victim.

>an administrative boundary.

A manager at a well known ESP told me that one of the free mail
suspects gave them a DKIM signing key.  (I forget whether it was A or
Y.)

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Aug 2015 15:56:36 -0700

> Indeed.  I agree with the advice to refrain from blaming the victim.

On the average, a failure of a new mechanism to fully interoperate
should never be cast as the responsibility of an entity that has been
functioning legitimately since long before the new mechanism was defined.

And to nitpick, I believe the relevant architectural classification for
the entity of concern here is "Mediator".  "Resender" is a subset and
does not cover, for example, Mailings lists or Gateways.  See RFC 5598.

> suspects gave them a DKIM signing key.  (I forget whether it was A or

Is SPF "alignment" a valid term here?  (The term does not appear in the
SPF spec.) I thought 'alignment' was first defined in this space for
DMARC and that it does not have formal meaning for SPF or DKIM.  I
assume what is meant is simply SPF validation.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 21 Aug 2015 16:16:45 -0700

Thanks to all who have contributed comments and suggestions. I'll wait
until mid-next week to fold them all into the document.

--Kurt

---

From: Franck Martin <[email-masked]>
Date: Fri, 28 Aug 2015 17:41:04 -0700

> otherwise it makes no sense in this paragraph.

done

> I think it better keeps the focus on what's relevant to DMARC and is

slightly reworded to still indicate SPF provides 2 identifiers.

> Page 6, section 2.3, paragraph 2.

done

>    Recipient receives the message from the Mediator rather than the initial

done

> text) since others may have different experiences.

There is M3AAWG BCP on parked domains that treat on this subject.

> don't want to reuse that, then come up with something more descriptive than

Bad idea, but I still see it in emails... so in practice is very much in
use, therefore I prefer to name it and say it is a bad idea.

> existing text here with a pointer).

hmm, let's see what you think of the text I provide.

> It does indeed

---

From: Franck Martin <[email-masked]>
Date: Fri, 28 Aug 2015 17:46:24 -0700

> does not cover, for example, Mailings lists or Gateways.  See RFC 5598.

ok, therefore moved to right section

> assume what is meant is simply SPF validation.

It is DMARC alignment with SPF, the confusion between SPF and DMARC-SPF
lives on...

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Aug 2015 20:43:09 -0700

> It is DMARC alignment with SPF, the confusion between SPF and DMARC-SPF

The term "DMARC alignment with SPF" has no meaning within the DMARC spec.

Per RFC 7489:

     Identifier Alignment:  When the domain in the RFC5322.From address
      matches a domain validated by SPF or DKIM (or both), it has
      Identifier Alignment.

That is, 'alignment' is with the rfc5322.From field.  Not 'with' SPF or
DKIM.  It is validated 'by' SPF or DKIM.

>      security risks which should be carefully managed.

I think that the intended meaning is:

   ...to avoid SPF validation issues, given the requirement for DMARC
alignment with the rfc5322.From field.

or somesuch.

d/