Re: [ietf-822] Aptness of DKIM for MLs

Douglas Otis <doug.mtview@gmail.com> Thu, 05 June 2014 18:34 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B01A02B8 for <ietf-822@ietfa.amsl.com>; Thu, 5 Jun 2014 11:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ64-oFqV0dq for <ietf-822@ietfa.amsl.com>; Thu, 5 Jun 2014 11:34:15 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1B91A0254 for <ietf-822@ietf.org>; Thu, 5 Jun 2014 11:34:15 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id ma3so1475674pbc.24 for <ietf-822@ietf.org>; Thu, 05 Jun 2014 11:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MRYTecBkiySQ49dwUkCZRFvE8ZH/ZzZY49w8MoDqPzg=; b=OZukGHjeCDnH/opNsfmh/PVHMI7uNWd0xEozNCHUIKZP6ZRdQSRsqITln7wKs338I6 k1aYqNHC/9z3vfH+pPjIFbG8u6VkREhNms2iAm9hXT/5ywksSqCE6jFIxKWHsBFo2irF 6/2JF7WCjy0iCwxPQh0lLKeN6i6MrM9TMlnpLb9SYOKW/ldywNdkChL4xoGisxEdKW4q egkfd6QxNTIcc+1keySjMXxXC5rlZW5YMx16aQmVT5+MTPu5xT3PmdHGmGpqKNNEPhSH ttQPB31xPl53B5dSknnOpAxiB7UzVjK6S9SwGs5jIfTkmL5Vyds+f6Hdms7hgx65+49G WgHQ==
X-Received: by 10.68.143.231 with SMTP id sh7mr78663749pbb.7.1401993249250; Thu, 05 Jun 2014 11:34:09 -0700 (PDT)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id zq5sm25725204pbb.37.2014.06.05.11.34.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:34:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0871B630-CB39-420A-8F7F-C56E5BEC1B55"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <536CAC9C.6080807@tana.it>
Date: Thu, 05 Jun 2014 11:34:06 -0700
Message-Id: <E3F12910-586E-4A55-9394-8146FCB5FABF@gmail.com>
References: <20140506171238.28535.qmail@joyce.lan> <536A05B2.9060805@tana.it> <6.2.5.6.2.20140508104525.0c42ac38@resistor.net> <536CAC9C.6080807@tana.it>
To: Alessandro Vesely <vesely@tana.it>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/2-igU3k9etIHObuSTLqQaL5gkuc
Cc: ietf-822@ietf.org
Subject: Re: [ietf-822] Aptness of DKIM for MLs
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 18:34:18 -0000

On May 9, 2014, at 3:23 AM, Alessandro Vesely <vesely@tana.it> wrote:

> Hi SM,
> 
> On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote:
>> At 03:06 07-05-2014, Alessandro Vesely wrote:
>>> to "standardize" its syntax.[3]  It seems to me that eliminating some
>>> of such gratuitous changes is the solution to DMARC-for-MLs which
>>> minimizes the alterations in MLM software.  Are you sure it won't
>>> work?
>> 
>> This mailing list breaks the DKIM Signature.
> 
> No, it doesn't.  It broke elandsys' signature, but check tana's
> signature on this message.  (I send this to ietf-822 only, to avoid
> any confusion.)
> 
> So it seems I could publish a strict DMARC policy right now, and cause
> minimal disruptions.  However, some verifiers (NetEase) consider
> tana's h= inadequate, see "objection" below.
> 
>> Gratuitous changes to a mailing list message is a matter of
>> opinion.
> 
> Well, not exactly.
> 
> For corrections, section 6.4 of RFC 5321 is rather clear that
> submission servers MAY, while intermediate relays MUST NOT, apply
> certain changes.  So the range where opinions may vary is whether an
> MLM is to be considered akin to submission servers or relays.
> 
> By /gratuitous/ changes, such as adding/removing double quote marks, I
> mean unnecessary embellishments that were already disputable before
> DKIM took root.
> 
>> I suggest reading the past discussions first if you are interested
>> in trying to make it work.
> 
> Yes, much of this discussion was recited at the time of ADSP, for
> example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
> 
> The most relevant objection to weak signatures is why would domains so
> concerned about security as to publish a strong policy weaken their
> DKIM signatures?  A solution is to do so for ML messages only.
> 
> To recap, assume a domain has a DB of (user, mailing list) pairs which
> defines ML traffic.  Messages to ML are then sent in separate SMTP
> transactions and weakly signed.  MLMs sign those messages in turn,
> using strong signatures.  Verifiers derive the validity of MLM domains
> by comparing d= against To: or Cc: mailboxes.
> 
> Besides minor refinements, the major bar is to build that DB.  I
> proposed to do it manually for starting, and then find out how to
> automate its maintenance.

Dear Alessandro,

How can sending domains select the signature scheme?  For example, often there are other destinations cc'd.  Conveying an alignment exception method to all parties is the intent behind TPA-Labels.  This avoids the need to apply weak signatures that can be maliciously replayed.  After all, DKIM does not constrain possible recipients.  Good mailing lists are fairly keen at confirming subscriptions and do not represent a source of abuse.  If a spear-phishing problem is confronted, authorizations could require an ORA header be added. An easy feature to add to this scheme.

Regards,
Douglas Otis