Re: [ietf-dkim] Re: "I sign everything" yes/no

"Charles Lindsey" <chl@clerew.man.ac.uk> Mon, 27 November 2006 12:55 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gog12-0002Nc-8y for ietf-dkim-archive@lists.ietf.org; Mon, 27 Nov 2006 07:55:20 -0500
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gog0x-0000L7-NE for ietf-dkim-archive@lists.ietf.org; Mon, 27 Nov 2006 07:55:20 -0500
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kARCsLUE003662; Mon, 27 Nov 2006 04:54:22 -0800
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kARCs5sL003595 for <ietf-dkim@mipassoc.org>; Mon, 27 Nov 2006 04:54:05 -0800
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew&man^ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 456adfdd.85f6.502 for ietf-dkim@mipassoc.org; Mon, 27 Nov 2006 12:53:49 +0000 (envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kARCrlRS002086 for <ietf-dkim@mipassoc.org>; Mon, 27 Nov 2006 12:53:48 GMT
Date: Mon, 27 Nov 2006 12:53:47 -0000
To: DKIM <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] Re: "I sign everything" yes/no
References: <198A730C2044DE4A96749D13E167AD37E7E714@MOU1WNEXMB04.vcorp.ad.vrsn.com> <91A3FD7B-8B4A-4F78-9C5F-9BC66F86614D@mail-abuse.org> <4563C8D8.40909@santronics.com> <45647C86.36F3@xyzzy.claranet.de> <45648A1A.9030302@santronics.com> <op.tjg51tkv6hl8nm@clerew.man.ac.uk> <4567E1D7.6050002@cisco.com>
From: Charles Lindsey <chl@clerew.man.ac.uk>
Content-Type: text/plain; format="flowed"; delsp="yes"; charset="iso-8859-1"
MIME-Version: 1.0
Message-ID: <op.tjod3xh26hl8nm@clerew.man.ac.uk>
In-Reply-To: <4567E1D7.6050002@cisco.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Songbird: Clean, Clean
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id kARCsLUE003662
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4

On Sat, 25 Nov 2006 06:25:27 -0000, Jim Fenton <fenton@cisco.com> wrote:

> It's not entirely forgotten; section 2.3 of draft-allman-dkim-ssp-02  
> discusses multiple From addresses.  We thought about resolving the  
> ambiguity by (1) arbitrarily picking the first address in the From  
> header field, (2) picking the address in the Sender header field, or (3)  
> querying SSP for all addresses in the From header field, and combining  
> them somehow.  We picked (1), because we don't know whether the MUA is  
> going to display the Sender address or not, and we felt that it is  
> likely that it will display the first From address regardless.

And there I think you picked the wrong one. Why is whether the Sender  
header gets displayed by the MUA of relevance (though a decent MUA should  
give you the option of showing it)? Surely it is the MTA/MDA that does the  
verifying and that queries the appropriate SSP that needs to consider  
whether to use the Sender: or From: (for sure, full headers are available  
for inspection at that point). So I think you should have picked #2.

OTOH, if you or your MUA are sufficiently sophisticated to want to do the  
checks yourself, then you are presumably sufficiently sophisticated to  
cause the Sender: to be displayed.

I have seen sufficient comments from others to the effect that the Sender  
needs to be looked at in many situations that this matter probably ought  
to be reviewed (does that mean raising an Issue?).

Actually, I think we are all asking the wrong question, by starting from  
some header (From/Sender/Whatever). Surely a proper verifier should  
proceed something like this:

For each signature accompanying the message:

    Consider the Domain that created the signature

    For each relevant header (From, Sender, List-Post, etc)

       Note whether that Domain occurs in the address(es) in that header

    Consider the SSP of that Domain:

       Is the set of headers including (or not including) that Domain
       correct/reasonable/whatever?

Combine results from all signatures to arrive at final  
conclusion/score/whatever.

>  But we don't know how this will be displayed, and who the recipient is  
> likely to consider the author of the message, ...

I think it is more important who the  
originating/resending/forwarding/signing/SSP domain considered to be the  
author/sender.
so it's very difficult to decide


>> BTW, the bit in the base document that says the "From" MUST always be  
>> signed is wrong. It should have been the Sender, and maybe any  
>> Resent-From too. And that MUST is going to haunt us again when EAI ...

> The language here was discussed and determined by WG consensus.   
> Personally, I favored the language in -base-03 and earlier that says,  
> "any header field that describes the role of the signer (for example,  
> the Sender or Resent-From header field if the signature is on behalf of  
> the corresponding address and that address is different from the From  
> address) MUST also be included."

Yes, Im think you were right there, and if I had been a WG member at that  
time you would have had my support (though maybe not all the way up to  
"MUST"). I think it is up to verifiers to decide whether the correct  
headers have been signed to enable them to form a valid conslusion. For  
example, if the verifier saw that the message had been downgraded by EAI,  
it might take a very different view of which headers it wanted to see.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      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