Subject: [secdir] SecDir review of draft-ietf-dmarc-interoperability

From: Sean Turner <[email-masked]>
Date: Tue, 14 Jun 2016 15:42:12 -0500

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This informational draft describes interoperability issues between DMARC and indirect email flows as well as possible methods for addressing these interoperability issues.  Indirect email flows are messages that do not flow directly from the author's administrative domain to the final recipient(s).

Summary: I think it’s ready, but just wanted to check on one thing.  The difference between the following sentences in s1 and s4:

s1:  Note that some practices which are in use at the time of this document may or may not be "best practices", especially as future standards evolve.

s4: Note that these particular mechanisms may not be considered "best practices" and may, in some cases, violate various conventions or expectations.

made me wonder whether the two identified sections in the security considerations are the only sections that contain text that "violates various conventions or exceptions".  I don’t want wanting to grind the security axe on eMail, DKIM, SPF only on what’s changed.

Ramblings follow:

Rave:

Appreciate that this wasn’t trying to be passed off as a BCP and that there’s no 2119-language.

Appreciate your examples using TLS1.2 and at-this-time-known-to-be-good algorithms.

Rant:

s1 2nd para could probably be deleted.  It sounds a lot like marketing to me :)

Nits:

I found some.  Peter found way more so look for his GenArt review.

spt

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 15 Jun 2016 14:59:30 -0400

On Tue, Jun 14, 2016 at 4:42 PM, Sean Turner <[email-masked]> wrote:

> Summary: I think it’s ready, but just wanted to check on one thing.  The
> difference between the following sentences in s1 and s4:
>
> s1:  Note that some practices which are in use at the time of this
> document may or may not be "best practices", especially as future standards
> evolve.
>
> s4: Note that these particular mechanisms may not be considered "best
> practices" and may, in some cases, violate various conventions or
> expectations.
>
> made me wonder whether the two identified sections in the security
> considerations are the only sections that contain text that "violates
> various conventions or exceptions".  I don’t want wanting to grind the
> security axe on eMail, DKIM, SPF only on what’s changed.
>

The intent in s1 is to warn that, in general, some of the approaches have
various degrees of controversy associated with them at this time.

s4 is more oriented toward the "experimental" nature of some of the
mitigation strategies which are mentioned - without wanting to call out
particular approaches as being more or less controversial. s4 falls into
the scope of the explicit "possible mitigations" section of the document,
so we thought it important to re-iterate the caution which was initially
raised in s1.

--Kurt