[art] Review of draft-levine-herkula-oneclick

[Martin Thomson <[e-mail]>]

This draft seems pretty useful.  It's a very simple idea.  It needs
quite a bit of work before I would consider it fit for publication on
the standards track.

(Note: I reviewed -07; my review of the diff to -08 shows that there
are no relevant changes between the two versions.)

#1  Abstract and Introduction

The first rationale for this draft is completely wrong (abstract and
introduction, p1).  The need for one-click arises because MTAs want to
present UX for unsubscribing and the list providers generally don't
have any programmatic way to access this function.

The HTTPS URI in a List-Unsubscribe is intended to be opened in a
browser and shown to a user. This is what makes it unsuitable for
consumption by a machine or piece of software.  That's the relevant
point here.

That anti-spam software automatically fetches the link is what causes
GETs to these URIs to do the wrong thing is not something this draft
addresses.  It's something to bemoan, but you aren't going to get
people who deploy bad software to write good software by publishing an
RFC.  I would add this point as an aside, noting that this sad truth
is not one that this document will be likely to do anything about.

#2 Section 3.1

Can the List-Unsubscribe header field include more than one HTTPS URI?
 If it can, are all URIs expected to behave equivalently?

#3 Section 3.1

   The list of key/
   value pairs MUST contain the pair "List-Unsubscribe=One-Click".

This is a pointless requirement.  If the mailer wants to mark
one-click subscriptions specially, it can provide whatever string it
likes in the -Post header field.  (It could include that string if
that was what it wanted.)

#4 Section 3.1

   The URI and POST arguments SHOULD include an opaque identifier or
   other hard to forge component in addition to or instead of the plain-
   text names of the list and the subscriber.

This needs to be a MUST.

Is this both the URI and the -Post header field, or either?  I would
have said that either was OK.  You should note that the latter is only
OK if loading the URI triggers user authentication or some other
process that an attacker would be unable to complete.  However, this
doesn't prevent an attacker from unsubscribing a user if ambient
authority (e.g., cookies) were used to authenticate the user because
then the attacker could use the spam (or spear-phishing) trick.  If
ambient authority is used, then the URI MUST include the opaque
identifier.

Also, the entropy requirement needs to be explicit.  96-bits of data
that cannot be predicted by an attacker should suffice.  The security
considerations should observe here that all mail servers that receive
the message will be able to unsubscribe the user.  You should make a
point of that in the security considerations.

#5 Section 3.1; Section 8

   This will deter attacks in which a malicious party sends spam
   with List-Unsubscribe links for a victim list, with the intention of
   causing list unsubscriptions from a victim list as a side effect of
   users reporting the spam.

This is not the only way to cause a user to be unsubscribed if the
links are low entropy.  An attacker can just send POST requests if it
came to that.  You don't need to go to the effort of sending mail to
someone else unless the mailer is going to insist that the mail
receiver authenticate itself.  I don't see that as likely.

What you have created here is what is lovingly referred to as a
capability URI (more info: https://w3ctag.github.io/capability-urls/).
I would strongly encourage you to reference the W3C document here and
maybe give a brief overview of the hazards involved in this design.
It's a fine design, but not without risks.

#6 Section 3.1

   The One-Click action triggered by this URI SHOULD complete promptly
   and not burden the requester in an inappropriate way.

This has 2119-strength language, but I don't see how to enforce it.  I
totally get the next sentence, but if that is the extent of the
requirement, then this sentence doesn't need any of that language.
(Usually, prompt responses are of most benefit to the server, so
insisting on that isn't necessary.)

#7 Section 3.2; Section 5; Section 7.3

   The POST content SHOULD be sent as "multipart/form-data" [RFC7578]
   and MAY be sent as "application/x-www-form-urlencoded".

I think that this is crazy.  This implies that the contents of the
-Post header field is parsed by the mail receiver and then re-composed
into a different form.  I would prefer if the header field were
treated as an opaque string that was passed directly as the body of
the POST request.  This ensures a) that the information is unmodified,
and b) the that mail receiver implementation is as simple as possible.

I think that you could use text/plain with equal efficacy.  Or, better
yet, insist that the server not validate the content-type of the POST
request.  (Note that many implementations on the server side will
ignore the content-type header field when expecting form POSTs, but
insisting on "application/x-www-form-urlencoded" would be reasonable
if you are aware of server code that is deployed and cannot be
updated.)

For Section 5, I think that it would be sufficient to define this as a
completely free-form header field.

#8 Section 3.2

   The
   target of the POST action is the same as or similar to the one in the
   GET action for a manual unsubscription, ...

I don't understand this.  Isn't the target of the POST a URI from the
List-Unsubscribe header field?

Nit in this section: "the the HTTPS URI"

#9 Section 4

Just a question: is there any reason that you insist on DKIM, but
don't tie the DKIM information back to the URI in question?  Is there
any value in matching SDID to the hostname in the HTTPS URI?