Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft

Emil Gustafsson <emgu@google.com> Tue, 31 January 2023 21:25 UTC

Return-Path: <emgu@google.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 C197FC152577 for <dmarc@ietfa.amsl.com>; Tue, 31 Jan 2023 13:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.595
X-Spam-Level:
X-Spam-Status: No, score=-17.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQG4CjzK87qO for <dmarc@ietfa.amsl.com>; Tue, 31 Jan 2023 13:25:43 -0800 (PST)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795F1C152574 for <dmarc@ietf.org>; Tue, 31 Jan 2023 13:25:43 -0800 (PST)
Received: by mail-yb1-xb2a.google.com with SMTP id u72so19848404ybi.7 for <dmarc@ietf.org>; Tue, 31 Jan 2023 13:25:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hlvgl7VEmFep1e5Runkxi+0IhrnMt0MEcUAyRHgx33M=; b=V8FBuupNjSOSUAEjhxGeMNHozfIkgAJhcE4Ay7bxotq7e+0k++uB1jFAaVnp6NVeE0 2i8QTps0Tv2BEgCKMdxxn2TibhHXSY8RRrc2CzdjFOpBv/rxtf/7ZgsxXg7ofCF5/QaB C7WsijGDvBPGV4g6FR1S6ZH/YM3lcU2TyRq6cRdPv2KBvQ7E2M03KUlrJwFcWtMw+0Ap OsLZ7a+hhx6n/vwojWAEyTbPRykSOxDitm60U7CoZL9kxKgXCUvgKmbviuevDkHumkvH GtRyX8AF07/x/1EIVSxeGRQBsrzLwp2yF6qDmi5IO22iUavJES4FreqOr4FJsmighSMY 2kGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hlvgl7VEmFep1e5Runkxi+0IhrnMt0MEcUAyRHgx33M=; b=HgCLX7EeexkCFyz+XkbO99aamltb0PnuYtVC2QB2pZqZE/oJwdE4eP2kYpIAkCP94A ZAgQlBFD99alBsFovh9VSWzQfiiJRLqCW5Jelf7kwUT7eWwDEU38tOcwo4oHn/OpTu37 fYwtdTkthwINa6k8q17gqeX8nutn7MiC6y6VVkuHo6Yxl2t5lP81mcwPJpCV+BPFsCDE knkDHfArVR5hV+PPmuHO30mc2nugEdYdYkqOD0nh9/OCAolDInCg/73w7GDwl73P0qyB KC1SW884RW+t2PjccAFeuAif545YQDwCgihrXEzX4LKWvO8fNAG3NhGhH2bDtCQekuFx /18A==
X-Gm-Message-State: AO0yUKVEw3nHx2IbQpaw2n7YH5UaEFaWejtjOKUn86kXoTW54Qf2fypE N/IZxi9A6hlQodhKt2LGxUsKTS5kgculwEOngfI4Og==
X-Google-Smtp-Source: AK7set/ep2ZP9X8Nbu9rxnv2Ks06FWN0xtGgkw7njTw4OZWYiTpx2MGUX57R4CaPpTrzpCEo87LIbLtbrZQ26gKNGPA=
X-Received: by 2002:a5b:c8a:0:b0:801:e503:dd0c with SMTP id i10-20020a5b0c8a000000b00801e503dd0cmr43133ybq.384.1675200342285; Tue, 31 Jan 2023 13:25:42 -0800 (PST)
MIME-Version: 1.0
References: <CABZJ8k=Rkh9+AoDA+N2tawU+GkizNRS-MG14sRayYHWBmFP62A@mail.gmail.com> <20230131193010.EC345851C6F8@ary.qy> <CAHej_8kkq_RBwE-sRcy0GbJ8NPXqRw25=wirgig+uB36uvbzvA@mail.gmail.com> <CABZJ8kmbWGpZ-JBEN_hzf5K5X-PbXY0r0WGu2rwfUyi-i6na0Q@mail.gmail.com> <0b43a598-0905-bd3d-ed09-aa9d97a72764@taugh.com>
In-Reply-To: <0b43a598-0905-bd3d-ed09-aa9d97a72764@taugh.com>
From: Emil Gustafsson <emgu@google.com>
Date: Tue, 31 Jan 2023 14:25:29 -0700
Message-ID: <CABZJ8k=GvBuZey1ZuBgOjVK8L+WuN0E=MpEptjUTTD-Yy1HRLQ@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Cc: Todd Herr <todd.herr@valimail.com>, Scott Kitterman <sklist@kitterman.com>, dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000054ce2c05f395f913"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/yPO-qbh30taozi8ZBIlzjX7rLp0>
Subject: Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 31 Jan 2023 21:25:47 -0000

Yes, I know that unrestricted TLDs would not publish a PSD record (and even
if they did I agree that we probably want to ignore it). I should have
modified the example to eliminate that confusion.

The question regarding sending reports for existing vs non-existing domain
to a PSO came up in a discussion with Scott et.al in December. The short
version is that we have some concerns about sending aggregate and failure
reports to PSOs for existing domains. But I don't think there will be a
problem to send reports for non-existing domains.

I agree that it might make sense to modify parts of the privacy
considerations regarding multi-organizations PSDs like .com. But for the
rest I think it is good to call out the considerations as different mailbox
providers may have different levels of comfortability when it comes to
sending reports to a PSO.

I agree it is convenient for a PSD (like .bank) to rely on DMARC reports to
detect when a customer is missing a DMARC record, but since there are
mailbox providers that do not send DMARC reports I think it would be better
for the PSD in that case to rely on a different approach to identify
non-compliant customers. However I think the non-existing domains reports
are important to detect spoofing/phishing attempts in .gov and .mil type of
organizations.

/E

On Tue, Jan 31, 2023 at 2:06 PM John R Levine <johnl@taugh.com> wrote:

> > example, but what matters is really the existence of example.com as I
> think
> > the purpose is to not leak information to a PSO for a domain that do
> exist
> > without a DMARC record.
>
> The ENTIRE POINT of PSD records is to send reports about subdomains that
> exist but don't have their own DMARC records, so the PSD can tell the
> subdomain to fix it.
>
> The only domains that will ever publish a PSD record are ones like .BANK
> and .INSURANCE that have contracts with their registrants, or like .GOV
> that are effectively a single organization.
>
> There no chance whatsoever that .COM or any other unrestricted TLD will
> ever publish a PSD record.
>
> Now that I look at the privacy considerations, we need to rip out stuff
> about Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
> usage because it makes no sense, and the bit about nonexistent only doubly
> makes no sense since it's impossible to implement.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>