Subject: [ietf-dkim] NEW ISSUE: SSP applies only to receive-side filtering engine and not end-users

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:29:48 -0800

> 8. Filter Engine vs. End-user as SSP Target
> 
> Human Factors ("usability") design is an arcane topic largely resolved only by
> experimentation.  Certainly effective design of user interfaces is a black
> art.  As a consequence, the IETF has made it a practice to avoid the topic
> entirely.  This issue came up repeatedly during the early -- and later -- days
> of DKIM and was resolved by deciding that DKIM's target is the receive-side
> delivery filtering engine, rather than the human recipient.
> 
> The current SSP has re-introduced a range of assumptions about use with human
> recipients, and has used those assumptions for dictating specification
> details.  The specification needs to remove all consideration of human issues
> or else to provide substantial empirical basis for its inclusion. 

To the extent that the above is not sufficiently clear:

    The SSP specification needs to remove all references to end-users, human 
factors, or the like and it needs to remove all consideration of them from its 
design.

Absent that removal, the working group needs to develop an empirical basis for 
specific human factors assertions that drive the design and demonstrate 
working group consensus that these assertions are valid as well as necessary 
to the use of SSP.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 20:34:48 -0500

Dave Crocker wrote:

>     The SSP specification needs to remove all references to end-users,
> human factors, or the like and it needs to remove all consideration of
> them from its design.
> 
> Absent that removal, the working group needs to develop an empirical
> basis for specific human factors assertions that drive the design and
> demonstrate working group consensus that these assertions are valid as
> well as necessary to the use of SSP.

+1

There's still a lot of experimenting to do before we'll be able to call
any authentication-related user interface element a "best" practice.
Those experiments can't occur until DKIM (and probably SSP) has wider
adoption.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 13 Dec 2007 12:34:17 -0000

> Those experiments can't occur until DKIM (and probably SSP) has wider

I think the sort of language you would use, having described a  
standardized set of features, would be of the form "These features are  
*intended* to be used by verifiers in the following manner. ...". Whether  
they turn out later to be "best practice" will be clear when "later"  
happens. In the meantime, it gives verifiers an indication of what they  
should try to achieve, but still gives freedom to imaginative verifiers to  
use alternative strategies that will, hopefully, work even better.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Dec 2007 14:52:39 +0100

> Those experiments can't occur until DKIM (and probably SSP) has wider

I strongly disagree.  Many IETF protocol specifications have the user
interface in mind from the get go.  This is particularly true in mail. 
Take the simple construct of the Subject: line.  It is there because
users need a summary of an email, and it is the semantic equivalent of
RE: on a letter.  Netnews is the same way with the Newsgroups:
construct.  That is there because users are interested in specific bits
of information.  No human factors experts were involved in the creation
of Email or Netnews protocols.  I know.  I was there for the latter. SSP
does NOT tell applications what to display or how to display
information, but rather makes basic observations and conclusions about
behavior of users and spammers that we see today.  That is: users look
at From lines and spammers and phishers try to fake them.  Anyone
DISAGREE with that assertion?

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 13 Dec 2007 15:40:49 +0100

Eliot Lear wrote:

> SSP does NOT tell applications what to display or how to display
> information, but rather makes basic observations and conclusions
> about behavior of users and spammers that we see today.  That is:
> users look at From lines and spammers and phishers try to fake
> them.  Anyone DISAGREE with that assertion?

Yes.  With any decent MUA offering a choice of displayed header
fields I very often pick "all" or anything else resulting in "more
than the default".  Where possible I'd of course pick Resent-*,
Sender, Return-Path, Reply-To, Newsgroups, Followups-To, etc. as
"relevant".  Resent-* is so rare that displaying it "always" is no
real issue.  I read all mailing lists as "newsgroups" on GMane,
therefore "always displaying Sender" also is no real issue for me.

Folks still believing in From header fields haven't met spam so
far, but sooner or later they'll learn.

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 06:50:47 -0800

> Take the simple construct of the Subject: line.  It is there because

Very, very little IETF work has had user interface in mind.  Some work has 
user "information" in mind, but that is quite different.

The example of email is restricted to very, very well-established models, such 
as the office memo.  Hence it was sure to plug into human communications quite 
naturally.

That's not true for anything like what is being discussed here.

>   Netnews is the same way with the Newsgroups:

huh? What is the basis for believing it is useful to the general population of 
users?  (I don't mean what was intended, I mean knowing that it is broadly 
useful.)

> of information.  

One of the challenges in having human factors discussions in geek circles is 
the need to be very careful to distinguish average, mass market users from 
geeks.  This is an issue of defining the population properly and sampling it 
properly.

For quite a few critical factors, we ain't nuthin' like them.

> No human factors experts were involved in the creation

There is a difference between what the engineers designing something think 
will be useful, versus what actually will be useful.

Designing user interface details is a sufficiently heuristic process that it 
is essentially impossible to predict exactly what will work.  Expertise can 
produce an initial design that has lower risk, but not one that is guaranteed 
to be acceptable.  Only testing of the construct can do that.

(I recently had the fun of being a subject for a design at a well-known apps 
company.  They have a massively successful track record.  So imagine my 
surprise at how unusable much of their prototype was...)

I'll refrain from launching into a lecture about cognitive load, 
attention/distraction, and the rest of that domain.  It's not stuff we deal 
with in the IETF but it is fundamental to usability design.

> DISAGREE with that assertion?

Users mostly look at the display string of the From line.  Users are generally 
lousy at distinguishing particular domain names and matching correct ones to a 
brand, versus cousin domains.  DKIM and SSP provide no protection against these.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 13 Dec 2007 15:52:31 -0000

> That is: users look at From lines and spammers and phishers try to
> fake them.  Anyone DISAGREE with that assertion?

Of course you're wrong.

Except in the most primitive MUAs (which are surely far more popular
with people here than with Internet users in general), what the user
sees isn't the From: line, it's something the MUA concocts using the
From:, Sender:, address book entries, and random other stuff.

If I am using a recent version of Thunderbird in a normal
configuration, what will I see if a message has this From: line?

  From: [email-masked] <[email-masked]>

Sometimes the bad guys fake the From: line address, a lot of times
they don't even bother.  It is ridiculous to assert that anything like
SSP would make a meaningful difference in the amount of phishy stuff
MUAs show their users.

R's,
John

PS: I can't wait for someone to say "well, then MUAs will all have to
change to show the real address".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 13 Dec 2007 18:16:07 +0100

John Levine wrote:
 
> I can't wait for someone to say "well, then MUAs will 
> all have to change to show the real address".

That line of arguments was already used for PRA, and
while I dislike PRA that's no justification to invent
a worse "first author" concept.  The PRA supporters
at least control a significant portion of the market.

 Frank

---

From: "J D Falk" <[email-masked]>
Date: Thu, 13 Dec 2007 12:52:18 -0500

> SSP would make a meaningful difference in the amount of phishy stuff

Right, first we have to decide which color the MUA will paint the
background of the From: header to indicate whether it's trustworthy or
not.

(This is a joke, of course -- but not entirely.  I actually had that
conversation in my last job.  I bet some of the rest of y'all have, too.
There's no best practice to fall back on yet.)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Dec 2007 23:36:13 +0100

Frank,

> than the default". 

I now get what people are saying, thanks to you and John Levine in
particular.  I still believe that the From address requires protection
in SSP.  UIs can at least take a stab at protecting the user by matching
display strings to what is in their address book.  They can also warn
people about SSP or DKIM "protected" domains that have not previously
been seen to prevent the spammers' favorite trick of being the first to
use technology ;-)  That's not something we can or should standardize
here today, but let's also not throw the baby out with the bath water.

Eliot

---

From: "J D Falk" <[email-masked]>
Date: Thu, 13 Dec 2007 18:32:11 -0500

Eliot Lear wrote:

> in SSP.  UIs can at least take a stab at protecting the user by
> matching display strings to what is in their address book.  They can
> also warn people about SSP or DKIM "protected" domains that have not
> previously been seen to prevent the spammers' favorite trick of being
> the first to use technology ;-)  That's not something we can or should
> standardize here today, but let's also not throw the baby out with the
> bath water.

I also believe that user-visible information should be more trustworthy
than it is today, but I don't think that protection should be shoehorned
into DKIM+SSP.  The real problem is that most MUAs simply don't show
users the more reliably trustworthy identities, and we won't fix that
here.

What we /can/ do is strengthen the identities that DKIM already deals
with, and thus enable MUA developers to experiment with different ways
of showing this information to the users.