Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

Dave Crocker <dhc@dcrocker.net> Fri, 31 May 2019 13:50 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E612002E for <dmarc@ietfa.amsl.com>; Fri, 31 May 2019 06:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 Vpt3VH5CKsl8 for <dmarc@ietfa.amsl.com>; Fri, 31 May 2019 06:50:29 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4251120025 for <dmarc@ietf.org>; Fri, 31 May 2019 06:50:29 -0700 (PDT)
Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4VDqWCA017622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2019 06:52:33 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559310755; bh=fTMYAaru9mIhsKIr6iNzh5iwjWl5PboW6B/k6xuIKtg=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=I9Um0GQrWOoeMwotB7LQWDOfaHUMTAJQGo4r9QwoRM7EMLMhsEd+efE3SCqZ4uOeb XKWvU/k07bcebkAWx/eViBomPfKheE6NN3FtvqGOcrIPSpApJn+Mv+dVtvv5Qrb+eE 0nXwBVscVa5zuy/e7jutWRTSTRw+UcE/pgMAi4Lo=
To: Doug Foster <fosterd@bayviewphysicians.com>
Cc: 'IETF DMARC WG' <dmarc@ietf.org>
References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <CAL0qLwbxwLTpgYJN9qBTzi2oN1EMvAYuNoDbw5Rx5W46-WNyLA@mail.gmail.com> <alpine.OSX.2.21.9999.1905301712140.76792@ary.qy> <c559a331d90b49eba5b5f6e35ff4774a@bayviewphysicians.com> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Message-ID: <c814e31d-88f9-52bd-01f9-935396ea5f76@dcrocker.net>
Date: Fri, 31 May 2019 15:50:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <000001d517a9$8c4f5960$a4ee0c20$@bayviewphysicians.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MuSbQF9ABZMRAD7XjulxZYA_SQ0>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 13:50:31 -0000

On 5/31/2019 5:08 AM, Doug Foster wrote:
> Tactically, what I meant was "IETF should be able to ensure that IETF
> messages are only released with verifiable IETF signatures".

I'm not exactly sure what the above sentence means, in terms of 
technical details.  So while the language all sounds fine, its meaning 
is far more ambiguous that I suspect you intended.

In any event, are you aware of the recent work on ARC?  For some case(s) 
of what you might mean, above, that's it's goal.


> This would mean that either the first signature is not applied, the message
> is not altered after the first signature is applied, or the first signature
> is removed after the message is altered.   The current configuration leaves
> open the suspicion that IETF has rogue software operating in its

A message from the IETF list processor has an ietf.org DKIM signature. 
How does that support your concern?



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net