Re: [ietf-dkim] A more fundamental SSP axiom

[Michael Thomas <[e-mail]>]

John L wrote:

>> Please don't shoot the messanger: I'm just asking.
>
>
> I hadn't intended to shoot, sorry if it came across that way.  You're 
> right, people find all sorts of other uses for successful protocols, 
> but those uses tend to be "pull", repurpose info already used for 
> something else rather than "push", stick in the data and see if anyone 
> cares.  The way we're trying to define SSP is really risky since we 
> have, as far as I can tell, no operational experience at all with 
> anything SSP-like so we're just guessing about what will be useful.
>
> It seems to me that so far we have two, maybe three, items that a 
> sender could publish that would plausibly be useful to a recipient 
> trying to decide what to do with an incoming message that isn't 
> self-signed.
>
> "I send no mail" is about the strongest possible hint that the message 
> is forged, and the recipient doesn't want it.
>
> "I sign all mail" is the next strongest hint, saying to me that the 
> sender believes it has its outgoing mail firmly enough under control 
> that an unsigned message is more likely to be a phish than a damaged 
> real message.


As I've said before, there are really two different subclasses of this one.
You can have your mail very well under control, but you don't have
control over what the damage might be in transit. For some people
like banks and phishing targets, that collateral damage is likely to be
acceptable. For most everybody else it's not.

So I guess it just intrinsically bugs me that the former is a pretty 
rarified
class  of sender, and is SSP really _only_ for them? (leaving I send
no mail aside).  Is there little or no value in knowing that you sign
everything, but transit related damage is possible?

>
> The third is "<foo> signs all my mail", if it turns out that there 
> actually exist foo's that reliable enough to delegate's one's signing, 
> and that it's easier to do that than to sign in the MUA or to provide 
> signing keys so that foo can put on the sender's signature.


This is sort of orthogonal to the previous: it's just saying _who_ is doing
it, so the previous considerations of "I sign all mail" still appy.

>
> So my suggestion would be to use a format similar to the one we use 
> for the signatures, put the first two items in the spec, and use a 
> syntax that permits people to experiment with new items and propose 
> the useful ones for later standardization.
>
I'm mostly on the keep it simple side as well -- I'm mainly pushing on these
things to get issue out in the open so they can be considered and likely 
closed.

I have seen some pushback on "standardize later" tact, but I think 
you're right
that this isn't the same as, say, dkim-base where we're not very likely 
to get an
opportunity for version 2.0. But it shouldn't hurt to just add
stuff to the policy record -- possibly non-standard experimental stuff 
-- and
if it's useful and relevant, users of the protocol will almost certainly 
have an
incentive to upgrade their software to take advantage of it. This is in 
stark
contrast to the -base upgrade problem where the signer has no clue of the
capabilities of the receiver, so backward compatibility is huge concern.

       Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html