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

["John Levine" <[e-mail]>]

Thanks for your review.

>#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.

No, really, the motivation is what we say it is.  A decade ago,
list-unsubscribe URIs unsubscribed you on the GET and returned a page
saying goodbye so you could script them.  The anti-spam fetches made
the GETs ambiguous, and provoked the confirmation pages.

I suppose I can reword it, although the people who've implemented
it don't seem to have any trouble understanding the motivation.

>#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?

For this spec, you only get one.

>#3 Section 3.1
>
>   The list of key/
>   value pairs MUST contain the pair "List-Unsubscribe=One-Click".
>
>This is a pointless requirement.

The mailers who've implemented this disagree with you; they find it
useful to verify that the specific intention of the POST is a one-click
unsubscribe.  Do you see any reason it's so harmful that it's worth
breaking the existing implementations?

The latest version of the draft says that the -post header *only*
contains the "List-Unsubscribe=One-Click" tag, to prevent bad
guys from using it to remotely script arbitrary web forms.

>#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?

Just the URI since the -Post header contents is now fixed.

>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.

The latest draft also says don't send cookies or other context info.

>Also, the entropy requirement needs to be explicit.  96-bits of data
>that cannot be predicted by an attacker should suffice.

I think you're making unwarranted assumptions about the security goals
of the people who implement this.  List-Unsubscribe typically contain
mailto: URLs that aren't authenticated at all, and that hasn't been a
big problem in practice.  They want it to be non-trivial to fake an
unsubscribe, but I don't see any evidence that anyone expects military
level security here.  Also keep in mind that the identifier often is
a key to a record in the mailer's database with no relationship to
any other identifier in the message, so as long as the identifier space
is reasonably sparse, it's pretty secure.

>  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.

I suppose, but if someone's mail is going through hostile servers,
he's got worse problems than the occasional unsubscription.  Keep in
mind that the way this works, every recipient gets a separate
customized copy of the message, so only the recipient's own mail
servers are going to see it.  (If you're unfamiliar with the bulk mail
market, they all send separate copies anyway.)


>#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.

Honestly, I don't see either as likely.  I'll just take it out.

>
>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.

Sure.  Is there a more stable reference than a github file?

>#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.

SHOULD means "do this if you want to interoperate unless you have
a good reason to do something else."  I don't see where enforcement
is relevant.

>#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.

Yes, the mail receiver does that, but the people who have implemented
this like it just fine.  They typically hand it to a http client
library where it's treated like the contents of a web 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.

That would be bad, since that would let bad guys put arbitrary crud
into http requests.  It would also be a lot harder to program since
they'd have to go around the libraries they're already using.

>#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?

Editing error, it is indeed the same URI as the one you'd use for a manual unsub.

>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?

That's deliberate.  There's lots of service bureaus that send mail on
behalf of clients, the division of work varies a lot, and it's quite
common for the domain in the unsub URI to be different from all the
other domains in the message.  I asked a large mail receiver about
this, and he said the point of the DKIM signature is to have some
identity they can use to say yeah, this is someone we recognize as not
totally evil.

R's,
John