Re: Aptness of DKIM for MLs
Douglas Otis <[email protected]> Thu, 5 Jun 2014 11:34:06 -0700
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
--===============0519668268393867329== Content-Type: multipart/alternative; boundary="Apple-Mail=_0871B630-CB39-420A-8F7F-C56E5BEC1B55" --Apple-Mail=_0871B630-CB39-420A-8F7F-C56E5BEC1B55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2014, at 3:23 AM, Alessandro Vesely <[email protected]> wrote: > Hi SM, >=20 > On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote: >> At 03:06 07-05-2014, Alessandro Vesely wrote: >>> to "standardize" its syntax.[3] It seems to me that eliminating = some >>> of such gratuitous changes is the solution to DMARC-for-MLs which >>> minimizes the alterations in MLM software. Are you sure it won't >>> work? >>=20 >> This mailing list breaks the DKIM Signature. >=20 > No, it doesn't. It broke elandsys' signature, but check tana's > signature on this message. (I send this to ietf-822 only, to avoid > any confusion.) >=20 > So it seems I could publish a strict DMARC policy right now, and cause > minimal disruptions. However, some verifiers (NetEase) consider > tana's h=3D inadequate, see "objection" below. >=20 >> Gratuitous changes to a mailing list message is a matter of >> opinion. >=20 > Well, not exactly. >=20 > For corrections, section 6.4 of RFC 5321 is rather clear that > submission servers MAY, while intermediate relays MUST NOT, apply > certain changes. So the range where opinions may vary is whether an > MLM is to be considered akin to submission servers or relays. >=20 > By /gratuitous/ changes, such as adding/removing double quote marks, I > mean unnecessary embellishments that were already disputable before > DKIM took root. >=20 >> I suggest reading the past discussions first if you are interested >> in trying to make it work. >=20 > Yes, much of this discussion was recited at the time of ADSP, for > example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html >=20 > The most relevant objection to weak signatures is why would domains so > concerned about security as to publish a strong policy weaken their > DKIM signatures? A solution is to do so for ML messages only. >=20 > To recap, assume a domain has a DB of (user, mailing list) pairs which > defines ML traffic. Messages to ML are then sent in separate SMTP > transactions and weakly signed. MLMs sign those messages in turn, > using strong signatures. Verifiers derive the validity of MLM domains > by comparing d=3D against To: or Cc: mailboxes. >=20 > Besides minor refinements, the major bar is to build that DB. I > proposed to do it manually for starting, and then find out how to > automate its maintenance. Dear Alessandro, How can sending domains select the signature scheme? For example, often = there are other destinations cc'd. Conveying an alignment exception = method to all parties is the intent behind TPA-Labels. This avoids the = need to apply weak signatures that can be maliciously replayed. After = all, DKIM does not constrain possible recipients. Good mailing lists = are fairly keen at confirming subscriptions and do not represent a = source of abuse. If a spear-phishing problem is confronted, = authorizations could require an ORA header be added. An easy feature to = add to this scheme. Regards, Douglas Otis =20= --Apple-Mail=_0871B630-CB39-420A-8F7F-C56E5BEC1B55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><br><div><div>On May 9, 2014, at 3:23 AM, Alessandro = Vesely <<a href=3D"mailto:[email protected]">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite">Hi SM,<br><br>On Thu 08/May/2014 19:59:19 +0200 S = Moonesamy wrote:<br><blockquote type=3D"cite">At 03:06 07-05-2014, = Alessandro Vesely wrote:<br><blockquote type=3D"cite">to "standardize" = its syntax.[3] It seems to me that eliminating some<br>of such = gratuitous changes is the solution to DMARC-for-MLs which<br>minimizes = the alterations in MLM software. Are you sure it = won't<br>work?<br></blockquote><br>This mailing list breaks the DKIM = Signature.<br></blockquote><br>No, it doesn't. It broke elandsys' = signature, but check tana's<br>signature on this message. (I send = this to ietf-822 only, to avoid<br>any confusion.)<br><br>So it seems I = could publish a strict DMARC policy right now, and cause<br>minimal = disruptions. However, some verifiers (NetEase) consider<br>tana's = h=3D inadequate, see "objection" below.<br><br><blockquote = type=3D"cite">Gratuitous changes to a mailing list message is a matter = of<br>opinion.<br></blockquote><br>Well, not exactly.<br><br>For = corrections, section 6.4 of RFC 5321 is rather clear that<br>submission = servers MAY, while intermediate relays MUST NOT, apply<br>certain = changes. So the range where opinions may vary is whether an<br>MLM = is to be considered akin to submission servers or relays.<br><br>By = /gratuitous/ changes, such as adding/removing double quote marks, = I<br>mean unnecessary embellishments that were already disputable = before<br>DKIM took root.<br><br><blockquote type=3D"cite">I suggest = reading the past discussions first if you are interested<br>in trying to = make it work.<br></blockquote><br>Yes, much of this discussion was = recited at the time of ADSP, for<br>example <a = href=3D"http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html">http:/= /mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html</a><br><br>The most = relevant objection to weak signatures is why would domains = so<br>concerned about security as to publish a strong policy weaken = their<br>DKIM signatures? A solution is to do so for ML messages = only.<br><br>To recap, assume a domain has a DB of (user, mailing list) = pairs which<br>defines ML traffic. Messages to ML are then sent in = separate SMTP<br>transactions and weakly signed. MLMs sign those = messages in turn,<br>using strong signatures. Verifiers derive the = validity of MLM domains<br>by comparing d=3D against To: or Cc: = mailboxes.<br><br>Besides minor refinements, the major bar is to build = that DB. I<br>proposed to do it manually for starting, and then = find out how to<br>automate its = maintenance.<br></blockquote></div><br><div>Dear = Alessandro,</div><div><br></div><div>How can sending domains select the = signature scheme? For example, often there are other destinations = cc'd. Conveying an alignment exception method to all parties is = the intent behind <a = href=3D"http://tools.ietf.org/html/draft-otis-tpa-label">TPA-Labels</a>. = This avoids the need to apply weak signatures that can be = maliciously replayed. After all, DKIM does not constrain possible = recipients. Good mailing lists are fairly keen at confirming = subscriptions and do not represent a source of abuse. If a = spear-phishing problem is confronted, authorizations could require an = ORA header be added. An easy feature to add to this = scheme.</div><div><br></div><div>Regards,</div><div>Douglas = Otis</div><div><br></div><div> </div></body></html>= --Apple-Mail=_0871B630-CB39-420A-8F7F-C56E5BEC1B55-- --===============0519668268393867329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-822 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-822 --===============0519668268393867329==--