[dmarc-ietf] Fwd: Priming the Pump for Discussion - Ratchets
Douglas Foster <dougfoster.emailstandards@gmail.com> Sat, 17 July 2021 12:38 UTC
Return-Path: <dougfoster.emailstandards@gmail.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 CD5CD3A0C5B for <dmarc@ietfa.amsl.com>; Sat, 17 Jul 2021 05:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 2eZGkbZaJTUk for <dmarc@ietfa.amsl.com>; Sat, 17 Jul 2021 05:38:24 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9313A0C5A for <dmarc@ietf.org>; Sat, 17 Jul 2021 05:38:23 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id h24-20020a9d64180000b029036edcf8f9a6so12850972otl.3 for <dmarc@ietf.org>; Sat, 17 Jul 2021 05:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BFA+FJ8Zp95DT3NPcOKe2o7T1ZoMQ891Pr+VW3EgzJk=; b=hlCLxEYpF5M9lHwDWlwhPbRwmVpcQc0p75lvZxOsepkkncvShofGhPYB6XoOT9Vehf qAQ1WAa/yFnFBRtxwVNlzLKSV3BFzV5sZmp+Dw0oeskN6qHYP76nuIMWDWbaTgVoZ/74 4ieSt1XMdTn7f1RtAxrZV/hq8JNhnJm1ToaRVFvy1nIi/f/VcWazXQvh7xgQ7ZAolR+n y/6GMVQDUBkdIVMgm3u84bdIZNad3f4P1/o5u2gJTXJkoqcfqUXScgY+yqQXA7Ktdw9V ZKDqQrdnbOCY8pAQKWJfVXNLnMYIegUkP0+DhXmQF51881mHCPe7OdixeF5I3lzUrqcq aUYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BFA+FJ8Zp95DT3NPcOKe2o7T1ZoMQ891Pr+VW3EgzJk=; b=qWM87vdRa4kJhZoRSb0fvQjjli9dM/BaRAq5G3IPwfutXpMdsYgsD+pxOisNwl51Zn dZ2mqAlANkmC808V2opTCv8/P/pMskcIsox4HoAfxVOPM8QqGWj5VEeEbGRz7zey+lO4 gwfSqeX44/bljXq2oBMjdLx/Gv1wSseVXSl/P9wY1b1YN5gN3ptiaLbVVyvvhlcnMx3Z 4iv04rxyNe7zzusKGwAYDcG4JJkc9ALQ6k9UIb2PRmUf47JB0u2z/GetQOkQkJHr7JC4 Qm3VFD2OeMThthmZS0VHa4F0dye3ZPkr4EhzSNOvjwvucMHWOXOqP3eMak6SZym/Q7js r5gw==
X-Gm-Message-State: AOAM530xI9qEJJtZnhS3UhWr7BshqSqbnnYgcT3qnKVeS2ZeJfXMULps 485S7MnDEc/CFpyiqN6DON1VDofkowEGT1U3vyOnM7Ia
X-Google-Smtp-Source: ABdhPJx713O0l1eQDgt6F84ynhlRrbOsW5kxlaqQ8Hjwiufir9RWWy7n3D9Y17Lltaqyuo8Y2q5DAuP1C16li40m+WU=
X-Received: by 2002:a9d:6f84:: with SMTP id h4mr12324386otq.240.1626525502515; Sat, 17 Jul 2021 05:38:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8=yvgXP2WgHayhGU2Hg2E0RcNgZBFjfw1cM-qKWkTG-+w@mail.gmail.com> <d80b0a14-0f4d-8266-8d42-8d9a6b02413d@tana.it> <CAH48ZfyLvECR_nwLmw6R6RnE4EZa8g_i7MJaF32d2qk4RBCKRA@mail.gmail.com> <1E1F7937-AFEC-4F5A-8A5A-229A99C94E8B@bluepopcorn.net> <CAH48ZfyTm1PSANTUmnqOy3aeiW4JHGbTsQ-m9xtSW9zFaCUZQA@mail.gmail.com>
In-Reply-To: <CAH48ZfyTm1PSANTUmnqOy3aeiW4JHGbTsQ-m9xtSW9zFaCUZQA@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sat, 17 Jul 2021 08:38:13 -0400
Message-ID: <CAH48ZfzEWaFPUG4Gfc2ckpyUEq-8L9kEZZv+LwqJcW88=0y6=w@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cbad8c05c750faa4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/P0vjCBSGNQssncdOxzpR5IO3eV0>
Subject: [dmarc-ietf] Fwd: Priming the Pump for Discussion - Ratchets
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, 17 Jul 2021 12:38:29 -0000
The goal is to partition all incoming messages into two mutually exclusive groups: Those messages which originated under domain owner control, and those which originated under domain owner control, and those which originated outside domain owner control. This requires two things: - First, that at origination, credentials are in place so that a first-hop MTA can reliably perform this partitioning. I have a much longer analysis, but the short version is that this requires an aligned and verified DKIM signature on all messages. There is no partial participation, which is why the percentage notion needs to be discarded. Of course, fully authenticated messages are always detectable. However, in the absence of DKIM on all messages, the partitioning is not possible because both domain owner and non-owner messages will both fail to be authenticated. - Secondly, the message addresses and the associated DKIM credential must be preserved until the message is received. We know that this is not the case because forwarding with changes will break the DKIM signature. The absence of verification does not reliably indicate the absence of domain owner control, it can result from a domain owner message which was modified or a non-owner message which was received in transit for any reason. Consequently, we need three categories: 1) Messages which can be reliably attributed to the domain owner because authentication passess. 2) Messages which can be reliably attributed to non-owners because of a repudiation rule. 3) Messages which are ambiguous because they neither meet an authentication rule nor meet a repudiation rule. When we acknowledge this three-category reality, we have solved the mailing list problem. Mailing list messages can never be in category one. They belong in category 2. The current DMARCv1 specification forces them into category 3. The two-possibility worldview creates the problem. The three-possibility worldview solves the problem. I suggest these repudiation rules: Rule 1: The domain owner asserts that all messages from this domain will originate with a verifiable DKIM signature. If a message does not have an aligned DKIM signature, or does not have a DNS public key available for the scope ID, then the message originated outside domain owner control, As I have said, this is a mandatory first step to any policy being applied to non-authenticated mail. Rule 2: The domain owner asserts that all messages from this domain will originate with an SPF policy, including messages from email service providers. Results of SPF NONE or SPF NXDOMAIN indicate messages that are outside domain owner control. Rule 3: The domain owner asserts that all messages from this domain will have RFC5322.FROM addresses that "exist". Messages that do not have FROM addresses which "exist" have originated outside domain owner control. The definition of "Exists" is still being debated, and I have expressed strong feelings about the right definition. Rule 4: The domain owner asserts that all messages from the domain will originate with an initial ARC Set. Messages which do not have an ARC Set from the domain have originated outside domain owner control. I am inclined to include broken-chain ARC sets in this rule, but John would be a better person to clarify this question Everything that is not authenticated or repudiated is in category 2. I understand that category 2 includes a large number of messages. These messages require more analysis because the DMARC result is indeterminate. In most cases, this means that the next step is to put the message through the full suite of content filters. If the message is not blocked based on content filters, then it may be desirable to do an in-depth analysis of the message. Full header analysis is complex, ambiguous, subject to spoofing, and very much outside of the capabilities of this document. Note: I am being careful to use "outside domain owner control" because some such messages are very much wanted and should not be blocked. Even though such cases exist, the partitioning effort is indeed useful, because it can be used to block some unwanted messages. So "p=reject" fails on multiple levels: It presumes that the domain owner knows that credentials will be preserved until reception, which is false, and it assumes that non-credentials messages should always be blocked, which is also false. "Pct=50" fails because it presumes that partial participation is possible, and it presumes that a message evaluator will be willing to use a random number generator to decide message fates. Doug Foster Doug Foster On Fri, Jul 16, 2021 at 7:24 PM Jim Fenton <fenton@bluepopcorn.net> wrote: > On 15 Jul 2021, at 18:07, Douglas Foster wrote: > > >> The aligned DKIM signature test can have three conclusions, not just > two: > >> > >> · Fully Authenticated: A signature is present, a DNS public > >> key is available, and the key can be used to verify the signature. > >> > >> · Provided: A signature is present, and a DNS public key is > >> available, but the key cannot be used to validate the signature. > >> > >> · No Signature or No key: A signature is not present or is > >> present but the DNS public key is not available. > >> > >> If the domain owner indicates that all messages originate with a > >> signature, then messages with “No Signature or No Key” are verifiably > not > >> from the domain owner and can be confidently repudiated. > > Why would “Provided” be handled any differently from “No signature or no > key”? An attacker can easily provide a signature for a message they are > spoofing, and after observing some of that domain’s traffic will know what > selector name to use that has a published public key. > > DKIM is very explicit about its results: either the signature verifies or > it does not. There is no third case. > > -Jim >
- [dmarc-ietf] Priming the Pump for Discussion - Ra… Todd Herr
- Re: [dmarc-ietf] Priming the Pump for Discussion … Dilyan Palauzov
- Re: [dmarc-ietf] Priming the Pump for Discussion … Alessandro Vesely
- Re: [dmarc-ietf] Priming the Pump for Discussion … John Levine
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Todd Herr
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Priming the Pump for Discussion … Steven M Jones
- Re: [dmarc-ietf] Priming the Pump for Discussion … John Levine
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Todd Herr
- Re: [dmarc-ietf] Priming the Pump for Discussion … Jim Fenton
- Re: [dmarc-ietf] Priming the Pump for Discussion … Jim Fenton
- [dmarc-ietf] Fwd: Priming the Pump for Discussion… Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dotzero
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Benny Pedersen
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dotzero
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 tjw ietf
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Steve Siirila
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Matthäus Wander
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Дилян Палаузов
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… John R Levine
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Benny Pedersen
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Douglas Foster
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… John Levine