Subject: [secdir] Security review of draft-levine-herkula-oneclick-05

From: Ben Laurie <[email-masked]>
Date: Sun, 18 Sep 2016 17:07:20 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Status: ready with issues.

Broadly speaking, all seems fine with this draft, except the advice
given for making the header non-forgeable is weak.

"The URI and POST arguments SHOULD include a hard to forge component
such as a hash in addition to or instead of the plain-text names of
the list and the subscriber."

Hashes are not inherently hard to forge, they need to be combined with
a secret of some kind. Also, using a plain hash is error-prone. So
better advice would be something along the lines of

"The URI and POST arguments SHOULD include a hard to forge component
such as an HMAC (RFC 2104) of the other components, using a secret
key, in addition to or instead of the plain-text names of the list and
the subscriber."

Although its kinda obvious, you should probably also say that the
server SHOULD verify this HMAC.

Finally, since the URI argument is the subject of an existing RFC
(2369) that RFC should probably be updated to include this advice.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Sep 2016 12:18:37 -0400

> server SHOULD verify this HMAC.

It couldn't hurt, I'll put it into the -06.

> (2369) that RFC should probably be updated to include this advice.

I don't think that's right.  The usual way to verify a 2369 unsubscribe is 
to ask for confirmation, either in a web page if the URI is an http or 
https, or by writing back if it's mailto:.  That doesn't change for the 
current GET syntax of 2369.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ben Laurie <[email-masked]>
Date: Sun, 18 Sep 2016 18:05:51 +0100

> current GET syntax of 2369.

If the goal is to prevent spoofed mails leading to unsubscription,
then it applies in either case.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 18 Sep 2016 18:09:05 +0100

On 18 September 2016 at 18:07, John R. Levine <[email-masked]> wrote:
> It's only a goal here because they have other ways to do it if it's not
> one-click.

Ok, then in that case it seems like you only need to secure the POST
arguments, not the URI.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Sep 2016 13:07:13 -0400

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 18 Sep 2016 13:55:36 -0400

> Ok, then in that case it seems like you only need to secure the POST

There's several scenarios that this draft is addressing:

A) bad guy sends fake mail with real insecure opt-out link, MUA clicks it
indirectly when user hits the junk button

B) real message with real link is clicked by helpful anti-spam software, 
not the user

The hash stuff is for A, the POST is for B.  Since the POST gets both the 
URI and the arguments, the hash can be in whichever is operationally 
easier.  All the places that have rules about commercial junk mail say 
that if the recipient tells you to stop, you have to stop and "the link 
was in a fake message" isn't a defense. It's quite common now for the 
unsubscribe URI to be totally opaque, e.g., with a hash and a key the 
mailer looks up in a database to find the recipient's address, so that 
malicious parties can't guess other subscribers' addresses.  If they add 
POST arguments for one-click, they'll likely keep the existing opaque URI, 
and with the secure URI, the POST arguments tell it nothing beyond the 
fact that this is a one-click transaction.

In the two decades since 2369 came out, the URI stuff has become common 
knowledge among the narrow group of people for whom "deliverability" is an 
adjective.  I really don't want to open up 2369 with this draft, because I 
don't think the small amount this draft says would be helpful.  It doesn't 
change the way people use 2369, it only adds a new way to do 
list-unsubscribe.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 18 Sep 2016 19:36:00 -0400

One other thought -- I think the most common thing that mailers do is to 
put the subscriber info into a database where each record includes a 
randomly generated key unrelated to anything else.  Then you put that key 
into the URI, no HMAC needed.

R's,
John

> B) real message with real link is clicked by helpful anti-spam software, not 
> the user
>
> The hash stuff is for A, the POST is for B.  Since the POST gets both the URI 
> and the arguments, the hash can be in whichever is operationally easier.  All 
> the places that have rules about commercial junk mail say that if the 
> recipient tells you to stop, you have to stop and "the link was in a fake 
> message" isn't a defense. It's quite common now for the unsubscribe URI to be 
> totally opaque, e.g., with a hash and a key the mailer looks up in a database 
> to find the recipient's address, so that malicious parties can't guess other 
> subscribers' addresses.  If they add POST arguments for one-click, they'll 
> likely keep the existing opaque URI, and with the secure URI, the POST 
> arguments tell it nothing beyond the fact that this is a one-click 
> transaction.
>

Regards,

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Sep 2016 12:06:34 +0100

> into the URI, no HMAC needed.

Yep.

>> easier.  All the places that have rules about commercial junk mail say that
>> if the recipient tells you to stop, you have to stop and "the link was in a
>> fake message" isn't a defense. It's quite common now for the unsubscribe
>> URI to be totally opaque, e.g., with a hash and a key the mailer looks up
>> in a database to find the recipient's address, so that malicious parties
>> can't guess other subscribers' addresses.  If they add POST arguments for
>> one-click, they'll likely keep the existing opaque URI, and with the secure
>> URI, the POST arguments tell it nothing beyond the fact that this is a
>> one-click transaction.
>>