--On Tuesday, September 13, 2016 13:49 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
Ah. That may suggest the disconnect we are having lies
somewhere other than in what I assumed. This document
appears to have been written for Standards Track and the Last
Call is for publishing it as a Proposed Standard. That
implies at least a plausible assumption or realistic hope
that it will be implemented and deployed by multiple
independent parties. For that purpose, it just isn't
complete and doesn't contain enough information, with that
issue about hashes as one example, perhaps among many.
We already have two implementations in progress, at Gmail and
AOL, and as Tobias said, this got enough attention at MAAWG
that I think it's likely that other webmail providers will do
it, too, as will a lot of ESPs (bulk mail providers.) I agree
that it could use some more hints about unique URLs to avoid
forgery.
Yes, but, again, I think it is more than hints -- I think there
either needs to be enough information in the spec for safe,
interoperable, independent implementations to be created or that
it isn't appropriate for a Proposed Standard. For a situation
like this, "enough information" isn't present and "independent"
doesn't apply if either depends, not on the text, but on
side-discussions between implementers or in MAAWG (or other
bodies, even the halls of the IETF) unless the content of those
discussions is normatively references (and meets the RFC
Editor's criteria for accessibility of normatively referenced
materials).
I don't know where if anywhere this would go in the draft, but
the ESPs that are likely to implement this have rather
different concerns from discussion lists like this one. They
want the subscribers to get the mail, but they are much more
concerned about minimizing complaints for fear of their mail
going somewhere other than recipients' inboxes. If you make
the unsub process complex, a fair number of people will figure
(correctly for them) that it's easier just to report it all as
spam until it goes away.
So given a tradeoff between defending against fake
unsubscribes versus making it easy for people to mail the mail
stop, they'll pick the latter. I doubt this will ever make it
into Mailman, but that's OK.
The reason we're having this discussion is that Gmail noticed
that people used the spam button to unsubscribe, so they added
an option to the spam button to unsubscribe at the same time,
and for that to work they need to do it without further
interaction. It'd also be useful to automatically unsub from
mail to closed or abandoned mailboxes.
IMO, that motivation and perspective is very important. It is
clearly not how I was thinking about the problem.
After this (to me very helpful) discussion, let me summarize my
concerns and then move on -- if no one other than myself and
those directly involved care, I don't want to spend more time on
it. The two issues below are almost completely separate.
(1) Traditionally, the IETF makes standards _for the Internet_.
When the needs, perspectives, and views of tradeoffs of a few
very specific providers (whether specific by size or some other
criteria) are different from those of the vast majority of
providers (by count, not number of users or, in this case,
number of messages), then we have a problem that, as far as I
know, the IETF community has never really addressed. With no
disrespect to Google or AOL (or, in other areas and for example,
Cisco, Huawei, and Juniper) one extreme version of the question
is whether it appropriate for 600 pound gorillas or a consortium
or them to shape the Internet, even if that hurts or locks out
smaller providers or users with different profiles and needs.
I don't know the answer to any of those questions, nor to what
the IETF should do about them. They raise some old topics about
who really has change control of a suggested or approved
standard, but that is only part of the issue. IMO, a serious
discussion is probably overdue. I don't think that discussion
should be placed in the critical path of any given document if
we can process those documents without setting precedents that
preempt the discussion and its possible conclusions.
(2) For a proposed standard that meets both the criteria of RFC
2026 and successors and what I believe to be IETF's traditional
approach and role, I think this document needs a lot of work. I
think it should be explicit about use cases and motivations
(reflecting your comments above); that it should contain (or
normatively reference) enough information to permit
interoperable implementations and safe use without
side-knowledge that is not _very_ generally available; that it
should discuss difference (and maybe tradeoffs) among different
types of provider and user models; and that it should have a
sufficient discussion of security issues to permit readers to
assess risks, including risks associated with weak
implementations. I don't think our norms for Proposed Standards
permit a document to say "security is out of scope" or even
"deliberate malicious behavior is out of scope", so that needs
to be fixed.
With one possible exception, all of this second issue is about
the spec, not the header/protocol. The exception is that, for
interoperation this is appropriately safe, either you need to
describe the conditions for a sufficiently protective hash and
make its presence a MUST requirement or you need an in-depth
Security Considerations discussion about that issue.
YMMD and, again, I hope to not spend more of my time and that of
the IETF list on this document and the second point above (if
the first issue doesn't get some response in this thread, I may
start another one).
best,
john