Subject: [dmarc-ietf] DMARC & Lists - Minimal Change Set

From: Chris Meidinger <[email-masked]>
Date: Thu, 26 Jun 2014 21:13:17 -0400

Folks,

I've been thinking about this for a while, as I know many of you have. Obviously things have to change to some degree in order for domain owners and large operators to protect their email channels with DMARC and also allow list operators to remail their messages. There are a couple of thoughts I want to share with you and get some feedback on in terms of the minimum viable change set.

DMARC and traditional mailing lists don't play nice for two reasons: the subject is modified to add a prefix, which invalidates the DKIM signature, and the body is modified to add a footer, which again invalidates the DKIM signature. I find the former relatively critical - I get value from the modified subjects on all of my listmail. I do not personally find the latter particularly valuable, the footer is not useful to me personally. Regardless of whether a footer is desirable, it is easily configurable and list operators that want to avoid breaking DKIM/failing DMARC could omit it - particularly if that were all they had to do.

As far as the subject, I have been wondering whether not signing the Subject: header would be an option for large ISP's and large DMARC senders. It would increase the threat space by allowing replay of legitimate messages with weaponized subjects, but a) that's what everyone was able to do in the pre-DMARC days anyway and b) I'm not certain how real the threat is of someone clicking a link in the subject, where HTML etc are not viable to disguise a URL and the body is not modifiable to induce a click on the link in the subject header. 

So two questions to the group:

1: Regardless of whether it has simply always been that way, could list operators forego modifying message bodies by adding footers?

2: How real is the threat space of a modified subject? Would it be acceptable to allow bizarre subjects attached to otherwise intact and signed messages to pass DKIM and DMARC in the name of interoperability?

Looking forward to your thoughts,

Chris

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jun 2014 18:24:58 -0700

> Looking forward to your thoughts,

Dear Chris,

We have been ask to focus on Charter related issues. 

The subject can include URLs that get translated into potentially malicious links.
There is still the Intuit issue where a Sender signs the message.
All of these issues and more eventually relate to exceptions that a DMARC domain should be able to accommodate...

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2014 01:53:54 -0000

>DMARC and traditional mailing lists don't play nice for two reasons: the subject is modified to add a prefix,
>which invalidates the DKIM signature, and the body is modified to add a footer, which again invalidates the DKIM
>signature.

It's more than that.  Lists do all sorts of other stuff, from adding
body headers to reordering, stripping, or flattening attachments.

When we were doing DKIM we spent a lot of time trying to figure out
whether there was a way to make signatures that would survive mailing
list modifications with little success.  The l= option was intended to
allow lists to add footers, but I don't know of anyone who uses it.

To answer your specific question, I don't think modified subjects are
a huge threat, but the subject line isn't the problem.

R's,
John

---

From: Chris Meidinger <[email-masked]>
Date: Thu, 26 Jun 2014 22:00:03 -0400

> a huge threat, but the subject line isn't the problem.

Good input. Thanks for your thoughts on subjects - I obviously agree, but am very interested in outside input.

That said, would moving the goalposts to lists passing the body exactly intact as it was received (yes, it would take effort, but I'm talking about the goal line) and /not/ making any other changes get us closer to DMARC and lists happily co-existing? That appears to me to be a hell of a lot easier than many of the other things in discussion.

Chris

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Jun 2014 15:11:44 -0400

> 1: Regardless of whether it has simply always been that way, could list operators forego modifying message bodies by adding footers?

But will operators forgo adding footers for this as a standard 
practice?  You can't enforce this and you will find some that believe 
it isn't necessary to forego it.  In additional, in some 
jurisdictions, a footer is now legally required. Double check with 
CAN-SPAM.  CAN-SPAM basically says if a spammer follows certain rules, 
like adding an opt-out footer, then it is legally allowed to have a 
capitalistic right to exist.

> 2: How real is the threat space of a modified subject? Would it be acceptable to allow bizarre subjects attached to otherwise intact and signed messages to pass DKIM and DMARC in the name of intero…

I don't think the subject is a big thing. But anything is possible.

For my implementation design standpoint, the best one can do currently 
is to anticipate that a outbound message is going to target a 
particular site where you would have different "signing" rules for it. 
   For example, we have a configuration out of the box installation 
signing rules that applies to outbound expanded messages that have a 
"List-ID" added by our list server and for specific recipient addresses.

This is our wcDKIM INI configuration file. Read/Examine all the design 
considerations as the work was being done with the eventual default 
state conditions:

######################################################################
# Wildcat! DKIM (wcDKIM)
# (c) copyright 2011 Santronics Software, Inc.
# version: 3.10
#
# There are four main sections plus optional overriding Signing Rules
# sections:
#
#   [General]                 defines global options
#   [Signer.Defaults]         defines the default Signing options
#   [Verifier]                defines the default Verifying options
#   [Authentication-Results]  defines the default Reporting options
#
# See Signing Rules for examples of overriding the Signer.Defaults
# options.
#
# Technical Notes:
#
# MACROS:
#
# Several macros are available which will be expanded and set
# at run time:
#
#   {PRIMARY.DOMAIN}          Wildcat! Mail Setup Primary Domain
#   {VERIFIER.DOMAIN}         WCSMTP host domain when verifying
#   {AUTHOR}                  author address
#   {AUTHOR.DOMAIN}           author domain
#   {SIGNER}                  signing domain
#
######################################################################

#---------------------------------------------------------------------
# General Options
#---------------------------------------------------------------------

[General]
Enable.Signer          = 1          # set 0 to globally disable 
signing mail
Enable.Verifier        = 1          # set 0 to globally disable 
verification
FirstTimeSetup         = 1

#---------------------------------------------------------------------
# Signing Mail Setup. The default settings for [Signer.Defaults] are:
#---------------------------------------------------------------------

[Signer.Defaults]
Enable                 = 1                       # Default ON/OFF 
switch per signer
Signer                 = {PRIMARY.DOMAIN}        # signer domain for 
all outbound
Selector               = global                  # selector sub-domain 
for public key
Canon                  = simple/relaxed          # header/body 
canonicalization method
Hash                   = sha1                    # hashing method, 
sha1 or sha256
Identity               =                         # optional, if set 
adds i= tag, see below
AddBodyLength          = 0                       # optional, 1 - adds 
l= tag body size
AddTimeStamp           = 1                       # optional, 1 - adds 
t= tag timestamp
AddQueryMethod         = 0                       # optional, 1 - adds 
q= tag
AddCopiedHeaders       = 0                       # optional, 1 - adds 
z= tag
AddExpireTime          = 0                       # optional, days, 
adds x= tag
UseRequiredHeadersOnly = 1                       # optional, 1 - used 
RequireHeaders
RequiredHeaders        = 
From:To:Date:Message-Id:Organization:Subject:Received*:List-ID
SkipHeaders            = 
X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path
StripHeaders           =                         # optional, headers 
stripped by resigners
UserTags               =

# Notes:
#
# CANONICALIZATION (C14N):
#
# Possible values for canon= are either simple or relaxed or a combination
# listed below. They apply to both the the header and body in the format:
#
#   canon = HEADER/BODY
#
# The default is simple for both HEADER and BODY. simple keeps the data as
# is removing all final EOLs (carriage return, line feeds), while relaxed
# replaces tabs with spaces, removes of multiple spaces and EOLs.
#
#   canon = simple                simple applies to HEADER and BODY
#   canon = relaxed               relaxed for HEADER, simple for BODY
#   canon = simple/simple
#   canon = simple/relaxed
#   canon = relaxed/simple
#   canon = relaxed/relaxed
#
# HASHING:
#
# Possible values for hash=
#
#   hash  = sha1
#   hash  = sha256
#   hash  = both
#
# SIGNING HEADERS:
#
# When UseRequiredHeaderOnly = 0, all headers are signed except those 
in the
# SkipHeaders list. When UseRequiredHeaderOnly = 1, only the headers 
in the
# RequiredHeaders list are signed except those in the SkipHeaders list.
#
# Each header is the RequiredHeaders or SkipHeaders list are colon 
separated
# If you wish to sign or skip multiple headers, use an asterish '*' 
for the
# header, i.e. Received* for signing all Received: headers or or X-* 
for skipping
# all X- headers.
#
# USER DEFINED TAGS:
#
# The UserTags are experimental. They are additonal signed "tag=value;"
# information added to the signed signature.  The tag MUST NOT conflict
# with an DKIM standard tag.
#
# IDENTITY (i=)
#
# The optional i= tag allows you to add any valid formatted "email 
address"
# (but it doesn't have to exist).  It must be the same domain as the 
signer
# or a sub-domain of the signer.  Some macros are available:
#
#   {AUTHOR}           replace the Author (From:) address
#   {AUTHOR.DOMAIN}    replace the Author (From:) address domain
#   {SIGNER}           replace the signer domain
#
#   example: i= {AUTHOR}.{SIGNER}

#---------------------------------------------------------------------
# Verifier
#---------------------------------------------------------------------

[Verifier]
IgnoreBodyLengthTag       = 0    # 0 = honor l= length, 1 = ignore length
CheckPractices            = 1    # 0 = don't check signing practice, 1 
= check signing practices
CheckVBR                  = 1    # 0 = don't check VBR, 1 = check for VBR
SubjectRequired           = 0    # 0 = not required, 1 = subject is 
required to be signed
SaveCanonicalizedData     = 0    # 0 = canonicalized data is not 
saved, 1 = canonicalized data is saved
AllowUnsignedFromHeaders  = 0    # 0 = From headers not included in 
the signature are not allowed, 1 = allowed
IgnoreGranularity         = 0    # 0 = check sig tag i= granularity 
with policy g= tag, 1 = don't check
IgnoreExpire              = 0    # 0 = check expire, 1 to ignore x= 
expiration
FixSubjectHeader          = 0    # 0 = don't fix, 1 to capitalized 
Subject: header

#---------------------------------------------------------------------
# Authentication Results
#---------------------------------------------------------------------

[Authentication-Results]
Enable                   = 1
AuthenticationHost       = {VERIFIER.HOST}

#---------------------------------------------------------------------
# Signing Rules
#---------------------------------------------------------------------
#
# Before a signing can take place it must be enabled, a signer and
# selector must be set and the private key exist.  At a minimum, the
# Signer.Defaults section can be used to prepare the signing of all
# outgoing messages using the default settings defined, but you may
# override any of the default signing options by creating signing
# rules sections.
#
# A Signing Rule section allow you to change the Signer.Defaults
# options. The rules are checked from top down and the end result is
# a composite of the final signing options. Only the fields you wish
# to check need to set per rule. No need to duplicate them all.
#
# A Signing Rule has a format of:
#
#  [HEADER:VALUE]
#
# There are 3 main header fields checked: FROM, LIST-ID, and RCPT.
# Each rule value can have a wildcard spec:
#
#   [FROM:*]                check options for all messages
#   [FROM:[email-masked]]     check options for author's matching domain.com
#   [LIST-ID:*]             check options for all list messages
#   [LIST-ID:list-id]       check options for specific list-id
#   [RCPT:address]          check options for specific destination address
#
# You can check other message HEADER fields by defining them as well:
#
#   [HEADER:*]             check options for existing HEADER with any 
value
#   [HEADER:value]         check options for existing HEADER value
#
#---------------------------------------------------------------------

[from:[email-masked]]
Enable                 = 1
Signer                 = example.com
Selector               = beta1
AddExpireTime          = 60

[from:*]
Enable=1

[list-id:*]
Enable=1
AddBodyLength=0
StripHeaders=DKIM-Signature

# add body length tag for ietf.org list address
[rcpt:[email-masked]]
AddBodyLength=1

[X-NoSigning:*]
Enable=0

#---------------------------------------------------------------------

-- 
HLS