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

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

> You really need to explain that GET to the URI sometimes unsubscribes
> immediately (i.e., is unsafe) and sometimes shows a confirmation page.

I thought I did.  We seem to agree about what it should say, I'll see if I 
can make it clearer.

>>>   value pairs MUST contain the pair "List-Unsubscribe=One-Click".

> OK, now I'm really confused.  Why would you waste so many octets to
> send a single bit?

Basically, because we want to and it doesn't hurt anything.  At this stage 
I'd want a much stronger reason to change the running code than that it's 
ugly.

>>> [ re URIs and ]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.

> No, I'm not making assumptions, I'm describing what it takes to make
> something secure.  I would also assert that given how easy it is to do
> so, it's worth doing.

A list with a million names is quite large.  If there were a 40 bit 
identifier space, you'd get one in a million tries, a 50 bit space one in 
a billion, and since a try requires an http transaction, they are not 
particularly fast.  Where does 96 bits come from?

Also with respect to cookies and other context, the reason -08 says not to 
send them is to prevent marketers from connecting the unsub to the user's 
previous actvities in the scenario where it's coming from an MUA.  If a 
bad guy were scripting something and doing multiple unsub tries with the 
same cookies, that'd be an immediate tell.

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

Upon further thought, this is just wrong.  Humans need a fast response 
since they are impatient, but computers can be arbitrarily patient.   Out 
it goes.

[ re sending the POST argument as a web form ]

> Allowing mail receivers to modify the data makes this worse for the
> mail sender, who has to parse this gunk.  (I'm not the only one who
> thinks that HTML form posting is a legacy the web could happily leave
> behind.)

Perhaps, but the people who are using this use web forms all the time, 
notably on the two-click confirmation page, so the gunk parser is already 
there.  The libraries they use have well debugged support for forms, both 
sending and receiving.  I can believe that in whatever library one might 
use there is some way to send a blob and for the receiver to fetch it 
back, but in my apps using frameworks like Django or Bottle, the web form 
arguments show up as a dictionary for free.

If we were rebuilding the web from scratch, we would no doubt do this 
differently, but we're not.  This is a small tweak to systems that use 
forms now.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly