Re: [ietf-dkim] punting into near-term standardization

Douglas Otis <dotis@mail-abuse.org> Sun, 06 August 2006 10:04 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9fVC-0007vQ-KX for ietf-dkim-archive@lists.ietf.org; Sun, 06 Aug 2006 06:04:58 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9fVB-0006i5-5p for ietf-dkim-archive@lists.ietf.org; Sun, 06 Aug 2006 06:04:58 -0400
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 k76A2kY0022631; Sun, 6 Aug 2006 03:02:47 -0700
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k76A2MM0022540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Sun, 6 Aug 2006 03:02:22 -0700
Received: from [192.168.2.42] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k76A1utg020569 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 6 Aug 2006 03:01:56 -0700
In-Reply-To: <02d201c6b933$0ae07270$0201a8c0@hdev1>
References: <20060805034058.861.qmail@simone.iecc.com> <44D421F2.20705@dcrocker.net> <02d201c6b933$0ae07270$0201a8c0@hdev1>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <92F99928-8BB1-4DE8-9ABF-C0495D196986@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] punting into near-term standardization
Date: Sun, 06 Aug 2006 03:01:53 -0700
To: Hector Santos <hsantos@santronics.com>
X-Mailer: Apple Mail (2.752.2)
X-Songbird: Clean, Clean
Cc: dcrocker@bbiw.net, ietf-dkim@mipassoc.org
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
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3

On Aug 6, 2006, at 1:33 AM, Hector Santos wrote:

>
> ----- Original Message -----
> From: "Dave Crocker" <dhc@dcrocker.net>
> To: <ietf-dkim@mipassoc.org>
>
>>
>> The two that I vote for are:
>>
>> 1. I sign everything.
>> 2. I send no mail.
>
> Dave, these are ok, but please consider the implementations  
> considerations
> that were already discussed in the old list and well as here.
>
> Lets assume these are it.  How do implement it?
>
> Lets use an email example:
>
>    From: abc.com
>    DKIM-Signature: d=xyz.com
>
> In order to satisfy the checks, my verifier needs to a DNS SSP lookup.
>
> If the policy said "I send no mail", then is strong evidence that this
> message is unauthorized and unacceptable.  Agreed?
>
> If the policy said "I sign everything", then the existence of the
> DKIM-Signature is checked.  If it was missing, then is strong  
> evidence that
> this message is unauthorized and unacceptable.  Agreed?
>
> But it does exist, so you have two security questions here:
>
>     - Was a signature expected?
>     - Was a 3rd party signature expected?

Rephrase:
  Is this a designated signing domain?
  Do non-designated domains carry messages on behalf of this domain?

Non-designated domains carrying messages on behalf of a domain might  
be a mailing-list, an e-invite, a news article, an auction bid, etc.   
Although a domain may indicate that they have designated domains that  
sign all their messages, other non-designated services may not.   
Whether these other non-designated services are being used could be  
stipulated in the policy as perhaps representing an open/closed list.

> Lets handle the first question first - "Was a signature expected?"
>
> It is quite conceivable that during the migration period, many  
> systems will
> implement an DKIM verifier first before completely the DKIM signing
> component.  During this phase, it would not be signing message, so no
> message is expected to be sign.
>
> Understandibly, some people said that checking the KEY will fail so  
> this is
> basically the same "I never sign mail."

"I never sign" introduces a state tested against an invalid signature  
where not finding a key for a DKIM signature should be fairly  
suspicious by itself.  "No mail sent" provides a clear disposition  
for an invalid signature.  One would have to wonder about the  
motivation for making a "I never sign" assertion and how many would  
bother with it.

> But is not a 2nd DNS lookup. By simply adding policy "I never sign  
> mail",
> then the 1st SSP lookup would satisfy this requirement in an  
> efficient and
> optimal manner.

This seems to suggest that looking for policy precedes verification.   
Policy may or may not exist and may require several transactions.   
DNS transactions take awhile. The reason for questioning this, is  
that an open empty list should be defined as maybe signs as would be  
applied to any non-designated domain that might carry mail for the  
 From domain.  I doubt that many bad actors will attempt to spoof  
signatures without also knowing where a key exists within the domain  
to obtain a modicum of credibility.

> There could be other reasons why one may not want his mail signed  
> beside
> migrations, but migrations, to me, seems to be a good reason, in  
> fact, I can
> see us completing the DKIM verifier first before we get into the  
> signing
> part.  So I see this as a reasonable and practical situation.
>
> Now, the more complex issue is the second question "Was a 3rd party
> signature expected?"
>
> I believe this is where the major source of contention in  
> simplifying the
> policies vs. enhancing the security of the system.
>
> But consider this:  During the 1st SSP lookup, if there was a  
> policy "Only I
> sign mail", then we immediately resolve this condition with additional
> overhead or change in logic.   The verifier simply sees the  
> d=xyz.com and it
> will immediately now this is not a desirable condition expected by the
> domain.  1 DNS lookup is all that was required.
>
> So in opinion, there is sound technical reason to include:
>
>     "I never sign mail"
>     "Only I send mail"

Fine.

-Doug

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