Re: Review of: draft-otis-dkim-harmful

Douglas Otis <doug.mtview@gmail.com> Sun, 09 June 2013 17:43 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BEA21F8B98; Sun, 9 Jun 2013 10:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PZx9MKZWhn3; Sun, 9 Jun 2013 10:43:01 -0700 (PDT)
Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DFEAB21F8AE8; Sun, 9 Jun 2013 10:43:00 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id mc8so6489322pbc.18 for <multiple recipients>; Sun, 09 Jun 2013 10:43:00 -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:x-mailer; bh=bWkw7g37zIX6e1lWWbwbbdplwsK02CE71bFu9ux43Bw=; b=LdukkgqLaYBDrEaRoNNLi0jpAxrqDItu9UIHwPzEzXP8HfBL7dxAK0wewQID+Pl5f2 8Bxj4zvpBHXtPQRW+N6kXOFxbpOrc8k2/6ciTUoV7c/0qJRYFAREgmQheK4O4ei4+PgL 4zYyW/Sa8JLhL95aLGGwIoLtb/CM+47pegnriXn0RyBHcp/12DeY0Ce25/9C2wwZneWh l/d5WQnfVVY8fvHxAuPzg18a5vsQkfUnLmSH/e++cD1hXWh6zxSgQwvUazAw4Df/wv+O fmBdwd40FmajnrnKpjbxWMs3kPqhNeIBpz7QgMoEeXPF2jwSsnZHtk0nlFWyfL8geYNO 4dJA==
X-Received: by 10.68.213.101 with SMTP id nr5mr6835060pbc.22.1370799780613; Sun, 09 Jun 2013 10:43:00 -0700 (PDT)
Received: from [192.168.2.201] (c-98-207-206-162.hsd1.ca.comcast.net. [98.207.206.162]) by mx.google.com with ESMTPSA id bs2sm12121324pad.17.2013.06.09.10.42.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 10:42:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_49B9FC99-6988-4C17-8055-2A1CDDD67446"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Review of: draft-otis-dkim-harmful
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <CAL0qLwZ6t7TNvowfQwC53a8nZMtb-06B4zwB3=rWJW+EEpAKzg@mail.gmail.com>
Date: Sun, 09 Jun 2013 10:42:57 -0700
Message-Id: <8F830D23-443A-4437-B926-10972FEAAF6D@gmail.com>
References: <51907325.7050600@dcrocker.net> <0D5E55AA-D05F-4E4F-838E-00D0EF6FB27F@gmail.com> <51ADB6E6.5030300@dcrocker.net> <371CD7F9-8643-4214-B379-9497F71079A3@gmail.com> <CAL0qLwZ6t7TNvowfQwC53a8nZMtb-06B4zwB3=rWJW+EEpAKzg@mail.gmail.com>
To: "Murray S. Kucherawy" <msk@blackops.org>
X-Mailer: Apple Mail (2.1503)
Cc: iesg <iesg@ietf.org>, IETF Discussion <ietf@ietf.org>, Dave Rand <dave_rand@trendmicro.com>, Douglas Otis <doug_otis@trendmicro.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2013 17:43:02 -0000

On Jun 4, 2013, at 9:13 AM, Murray S. Kucherawy <msk@blackops.org> wrote:

> On Tue, Jun 4, 2013 at 4:08 AM, Douglas Otis <doug.mtview@gmail.com> wrote: 
> In its current form, DKIM simply attaches a domain name in an unseen message fragment, not a message.  The ease in which the only assured visible fragment of the message signed by the domain being forged makes it impossible for appropriate handling to be applied or likely harm prevented.
> 
> 
> There are existence proofs that contradict this claim.  They have been brought to your attention in the past.

Thank you for your response.  Could I trouble you for a reference to the proofs or for you to expand on what you specifically mean?  The draft otis-dkim-harmful addendum captured actual DKIM From header field spoofing delivered to the in-box for several major providers.

> It appears you're continuing to assign semantics to DKIM signatures that simply aren't there.  I don't know what else can be done to clarify this.

The semantics of d=domain and dkim=pass appear to be at the root of the problem.    What other semantics are you suggesting?

> Procedurally speaking, what path do you anticipate your draft following?

To require messages with invalidly repeated header fields to not return a "pass" for DKIM signature validation.

I apologize if I missed your response to a private query.   I hope to post an update shortly covering all expressed concerns.  

Regards,
Douglas Otis