--On Monday, September 12, 2016 09:58 -0700 The IESG
<iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'Signalling one-click functionality for list email headers'
<draft-levine-herkula-oneclick-04.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the ietf(_at_)ietf(_dot_)org mailing lists by
2016-10-10.
Hi. I've looked through this and find it a little troubling,
partially because I don't like the problem rather than not
liking the details of the solution.
I've seen deliberate attempts to disrupt mailing lists by
unsubscribing participants. While crude, a message to a user
asking for verification of intent to unsubscribe is an important
protection against that behavior. Similarly, having anti-spam
system follow/execute links in headers (as distinct from links
in message bodies) seems like a bad idea generally, but
verification messages or other two-step processes are an
important protection against accidental (but, IMO, badly
designed) or malicious bad behavior. So this specification
proposed a way to bypass those safeguards and protection? I'm
not convinced that is a good idea and what the document has to
say about it is
"This document does not address problems associated with
deliberate malicious behavior."
That seems to me to be equivalent to "we don't need to worry
about bad guys because they will never attempt to use this
feature". Really?
The one protection that it offers is DKIM verification of the
sending domain and headers. That is fine, modulo all of the
concerns about how easy DKIM is to spoof and the observation
that it really just validates a sending domain. However,
consider the following case, remembering that a message for
which this is relevant should be coming from a mailing list:
...
MAIL FROM:<evildoer(_at_)example(_dot_)com>
RCPT TO:<sucker(_at_)example(_dot_)net>
...
From: evildoer(_at_)example(_dot_)com
To: ietf(_at_)ietf(_dot_)org
...
DKIM-Signature: ...; d=ietf.org; ...
h=From:...:List-Unsubscribe:List-Unsubscribe-Post:...
...
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>,
<mailto:ietf-request(_at_)ietf(_dot_)org?subject=unsubscribe>
List-Unsubscribe-Post:
List-Unsubscribe=One-Click&recip=sucker(_at_)example(_dot_)net
Now the signature verifies just fine because the message was
sent from example.com, and the MUA promptly issues a POST that
removes poor Sucker from the IETF list. Even more interesting,
consider what happens if the last line of that example is
List-Unsubscribe=One-Click&recip=victim(_at_)example(_dot_)org
Unless I've misunderstood this feature, unless the list manager
does some checking --several versions of which checking this
mechanism is designed to eliminate or forbid-- the MUA (or
delivery server or anti-spam mechanism) associated with
sucker(_at_)example(_dot_)net promptly unsubscribes
victim(_at_)example(_dot_)org from
the IETF list.
Without studying the spec further, I'm not sure how much this
would help, but I'd expect to see at least a check that the
DKIM-signed sender domain for the list manager matches the
domains in the List-Unsubscribe field. Without that check,
this seems far too hazardous, even with a disclaimer that
malicious behavior is out of scope.
I do wonder about other topic areas in which one could create an
I-D and propose it for Standards Track by putting a short
section in the middle that says "This document does not
address...deliberate malicious behavior" and thereby avoid the
tedious and time-consuming requirement of BCP 72 to describe
what can go wrong with various types of easily-predicted attacks.
john