ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-08-01 04:43:44
On Tuesday 01 August 2006 05:12, Stephen Farrell wrote:
Scott Kitterman wrote:
Message from A, signed by A and B; does SSP matter? (I hope not.)

In my book it's the same as A signed by A.  The only concern I would have
is if B added content, what to do about that, I'm not sure.  I expect
that's probably a question for receiver policy and unlikely to be
standardized.

Message from A, signed by C; SSP says nothing about C.

Yes.  Then how to treat this would be a question of what A's SSP says (is
the list exclusive or not) and the receiver policy.

I still don't understand why we care if someone adds a signature and
does nothing else.

If B adds a signature covering a header not covered by A's signature,
then I can imagine that the verifier might want to treat that header
differently from those signed by A. But ignore that for now - if both
A and B sign exactly the same headers+content, then what bad thing
can happen? (That would cause A to want a countermeasure.)

Agreed, but in the multiple signature case my caveat was limited to the case 
of the second signer adding content.  If B adds a signature, but does not 
modify the content of the message, then I don't think the verifier would 
treat them differently.

As I read the later case, the only signature present (C's) is not one that is 
included in A's SSP.  In this case we have a message with a signature that is 
outside the scope what A has said is authorized (or not included in A's 
authoritative list).  If A is a high profile phishing target and signs all of 
it's mail, then it would be useful (I think) for receivers to recognize that 
the message has been signed by someone other than who A said it would.

I believe it's that distinction that gives DKIM the potential to be a useful 
(not a panacea, but useful) anti-phishing technology without having to layer 
a non-standard reputation system on top of it.

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