Subject: RE: [ietf-dkim] Policy decision tree outcomes

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 14 Nov 2006 08:57:28 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Tuesday, November 14, 2006 7:58 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Policy decision tree outcomes
> 
> On Mon, 13 Nov 2006 21:06:58 -0000, Hallam-Baker, Phillip 
> <[email-masked]> wrote:
> 
> > LEMMA-1: The objective of policy is to allow a verifier to draw 
> > conclusions from the absence of satisfactory authentication
> > PROOF:
> >     AXIOM-1:   The objective of policy is to influence the verifier
> >     AXIOM-2:   A verifier only looks at the policy record if
> > 		      it fails to find satisfactory authentication.
> 
> AXIOM-2 denied.
> 
> If it finds a satisfactory authentication from a signer with 
> an apalling reputation, it should be _very_ suspicious.

I disagree, there is no reason to doubt the authenticity of the message in this case. The message is authentic, the issue is authorization.

If the sender has an appauling reputation there is very little chance that its fake since its almost certain to go in the bit bucket anyway.

In fact if the sender has a bad reputation I will not even bother to verify the signature let alone the policy. I will return to this when proposing a processing algorithm for my policy mechanism. 

I don't see how reading a DKIM policy would modify the outcome here. If the message has a signature that uses a trusted signature algorithm it is going to be compliant with the policy 'I sign everything'. 

Even if the group accepted my proposal to allow selector contraints and a disparity was discovered we still have substantive proof that the message is authentic. It might possibly be worth logging as an anomaly but the only possible causes are administrator error (most likely) or the algorithm has been compromised (hopefully very unlikely).

> I am not clear what you mean by "acceptable/unacceptable signature".

A signature created with a trusted signature algorithm. So RSA2048 is acceptable RSA128 is an unacceptable signature.

> > LEMMA-2: There is no value in distinguishing between any of 
> the cases 
> > A, B, C, D
> >
> 
> >     AXIOM-4:    There is no value in distinguishing between 
> states that
> > 		can be reached by an attacker.
> 
> AXION-4 Denied.
> 
> Attackers can easily do bad things before the message is 
> submitted to the  
> MSA.
> 
> It is much harder to attack a message once it has left its 
> originating  
> MUA. You either need to have accomplices inside the ISP, or 
> to be able to  
> hack into it, or to have discovered a weakness in its 
> procedures, ... .  
> This limits the states that attackers can easily be reach, 
> and verifiers  
> are quite entitled to attribute more suspicion to the easier states.

OK: correction no point in distinguishing between states that are reachable with equal degree of difficulty.

> >     AXIOM-5: Stastes A2, B2, C2, D2 can be reached by an 
> attacker [by  
> > definition]
> >
> >     THEREFORE: LEMMA-2 follows.
> >
> FALSE

Lets look at the states again and how the attacker reaches them. I think that you are focusing on interception while I was thinking only about forged messages that were generated by the attacker without any reference.

A2: Message has no signature
	Attacker simply generates a fake email without a signature header in the normal fashion

B2: A signature is present with a signature type that the verifier cannot verify
	Attacker receives an email from the party it is intending to impersonate, reads the key record, determines that a rarely supported algorithm is listed, generates spoofed mail for that key record.

C2: An acceptable signature is present that failed verification
	Just generate some random Base64

D2: An unacceptable signature is present that passed verification
	Break the algorithm

So I would breakdown as follows:

A2: Trivial
B2: Easy if the sender being impersonated sends lots of mail otherwise security through obscurity
C2: Trivial
D2: Exceptionally hard even for 'broken algorithms'

The point about case D2 is that it only occurs if you have already decided that the algorithm is unacceptably insecure and thus that it is not worth distinguishing the signature from a forged one.

We might argue that there is value to making a distinction there but I am not seeing it.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Nov 2006 11:43:15 -0000

> In fact if the sender has a bad reputation I will not even bother to  
> verify the signature let alone the policy. I will return to this when  
> proposing a processing algorithm for my policy mechanism.

The apalling reputations I have in mind are when the signer is a known  
spammer who tries to dupe people by providing a valid signature which has  
no value. Oddly, in this case, it would have marginally more value if  
verification failed.

> OK: correction no point in distinguishing between states that are  
> reachable with equal degree of difficulty.
>
But there may well be value in distinguishing the likelihood of some state  
being reached accidentally rather than deliberately. So you might conclude  
that C1 was more (or maybe less) likely than C2, according to your  
esperience of how well genuine signatures survive on the real net. So if  
you are using spamassassin and applying a given score to a missing  
signatue (case A) you might apply a different score to a failed signature  
(case B) and a different score again to an unacceptable signature (case  
D). And the score would in all cases be adjusted according to the SSP  
reported by the signer.

-- 
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