Re: [dmarc-ietf] third party authorization, not, was non-mailing list

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Sat, 29 August 2020 19:42 UTC

Return-Path: <btv1==51050bea1be==fosterd@bayviewphysicians.com>
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 8564E3A0F99 for <dmarc@ietfa.amsl.com>; Sat, 29 Aug 2020 12:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
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 Il1GTBzzsRwI for <dmarc@ietfa.amsl.com>; Sat, 29 Aug 2020 12:42:48 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8863A0F93 for <dmarc@ietf.org>; Sat, 29 Aug 2020 12:42:48 -0700 (PDT)
X-ASG-Debug-ID: 1598730164-11fa31165b2ebf0001-K2EkT1
Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id hVrcyZx57sFdFZeZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sat, 29 Aug 2020 15:42:45 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=5g/KJSXBS2acSyN5K26iJnQXCJoLPMZl9NfUWLHQsuY=; b=CG573yWTG5zXNmvLBweMbcWPfE0BGUuSyqynQVfiov5CdchwpQMlO+GWH0FZmmnHi Ms9vMFKN4oiIpBZ04jnqSm+x3mgNTixQL8Z+orTNfxPeS5X2hRURV8xwG3E5kGj2H NzRoCVqRP5XbKJCTA98gVpyRrWMHgtTEjZqzfcUr0=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Date: Sat, 29 Aug 2020 19:42:36 +0000
X-ASG-Orig-Subj: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <613173c7fdfb4b40afdd80e2354f5042@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="e6762da219814772a2eba7f9c5535443"
In-Reply-To: <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net>
References: <20200824172403.A927C1F14BF5@ary.qy> <5fe7d5c2-7330-c9fb-2856-e7dfc2175c82@tana.it> <CAJ4XoYc1vutV61E-66DHWcdOxHmCUWiC0HC0AmiRYUcMxLgcCQ@mail.gmail.com> <1fe7a47f-4ebc-7621-2c1-e4803473e8d7@taugh.com> <CAJ4XoYf3_y4tb5JYm5fGndqxKN+070LvZ6i5kjHKqH0NnbHnhg@mail.gmail.com> <001801d67bce$bdf97510$39ec5f30$@bayviewphysicians.com> <CAJ4XoYdR-kHARvkYjbbyqoEnx8YV5RP4x1z40M3-z9ap1ypcRg@mail.gmail.com> <10ed5aec-7e4f-b6d4-0564-613fd92ebf72@bluepopcorn.net>
X-Exim-Id: 613173c7fdfb4b40afdd80e2354f5042
X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1598730165
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 5950
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84255 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/RUCMyN6o3ZkChyTk61IDot_Htp8>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
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: Sat, 29 Aug 2020 19:42:51 -0000

To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is computed.   The weak signature will not be unique because it will be computed on non-random content such as From, To, and Date.

However, the signature can only be used by the designated domain.   So the worst possible "misuse" would be for the designated domain to use the signature on other messages.   This seems unlikely, and the worst-case use is no different than what ATSP would authorize.   But the weak signature has less information leakage, since nothing is published in DNS about the signature technique.   So I agree that the approach is a good one for those who want to provide mailing-list authorization.

The remaining challenge is to communicate between recipient domains and mailing lists so that the list knows whether the recipient will honor the weak signature system.

Doug Foster

----------------------------------------
From: Jim Fenton <fenton@bluepopcorn.net>
Sent: 8/26/20 5:01 PM
To: Dotzero <dotzero@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/26/20 10:54 AM, Dotzero wrote:

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org> wrote:

Are the weak signatures vulnerable to a replay attack?    I thought that one of the reasons that DKIM signatures included the whole body was to prevent the signature from being reused.

 

DF

Not particularly vulnerable. The requirement is that you have the "weak signature" plus the intermediary full DKIM signature. This let's the validator/receiver know that the originating domain knew that the intermediary might break the originating domains DKIM signature but the validator/receiver would have the DKIM signature of the intermediary. The "weak signature" is only validated against that specific message and headers it signed and that specific intermediary. It's not a generic/general signature.

It sounds like the weak signature is just a regular DKIM signature plus the designation of the intermediary, and the "weak" part is that you don't check the body hash against the body. Have I got that right?

-Jim