Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Seth Blank <seth@valimail.com> Mon, 25 January 2021 18:03 UTC

Return-Path: <seth@valimail.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 3543F3A16B1 for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 (2048-bit key) header.d=valimail.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 NAsei8oc3stb for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:03:56 -0800 (PST)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 CC8AF3A175F for <dmarc@ietf.org>; Mon, 25 Jan 2021 10:02:25 -0800 (PST)
Received: by mail-vs1-xe31.google.com with SMTP id e15so7659023vsa.0 for <dmarc@ietf.org>; Mon, 25 Jan 2021 10:02:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J954iBVFrzOkUV/KX6b3nNuRLBvKqcOgZ/RtLzLc274=; b=bBe7ccWel4ZqS7mI12Up33ZDwvacnX9v1fRsBzkIPvUqHpeg0gvxg22ux+x26LU7JN bD2LRYXK6A618TsNEOFIpXehtllPDV1APjwXAMM6DIz72GvLf3fRLKs2mSjs1zZVT9fM UVwVc3oBe3VxED+7SlYtP82IukG0/stS6q6PZrqRNQscg9srLL0XEm8vuI4fYKRDHI/4 I27HTw+g14Wz1APS0GbXqFG2NjvPqw6EOR1h2kK0js9WRM2gYdkPfmgqnXNuJEmFxp/y Zy0+fhHfELKeL0xiwL8mWFi44PEcqbdzjFrR5OzgEWzYOeG+rasI9/+TLq3bR4LDprTA 6z2w==
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:cc; bh=J954iBVFrzOkUV/KX6b3nNuRLBvKqcOgZ/RtLzLc274=; b=LJsCHVCHojlSVXrNl7b05kJTS4LIcX52ZTvj0zAkUYbiSrL4dkELWIpQN6MMvjhfbl ekANBxA6BqWQdpeqQtS2IIpzvsM34mPvXN9I9UqNVNAUHl1wRYo67zSHrS325V8iwhXQ VogUtwsKbsmxVsyCi58AUB962n3WN/w5eibqaiIdDM3gJzyHiBIQmRDNymPdeHOG/sKJ D4EPmZA4COJ9Lk/ChvVDgL0dd7l9uANTi+CBrdeRoCF4Sushwj0dIkxg+u6DV5dFZyJK NtyTd1FH32nZ+XsKFr5uSw7o94sZ0TzuhmcT5ebAedHFOEzHwtmR0XN8xyQfaDlyU9aD CYlQ==
X-Gm-Message-State: AOAM532DGqjV9DPAQrlZKa+RaCU64nCH/RZN9BrNhLIVLNcIYHzTZN1K hxz3ClTrEN+8+A28fRQJLO9AFAiqYen5Eh8ty33ugA==
X-Google-Smtp-Source: ABdhPJx/5RZPt/sqtXOO/ZLOUrsJvcNTq/k60eD3E8XpkRtlZFDGYA9wEnxRXSXOHD5gmqNzfGjPuvxoavYr5zOh17U=
X-Received: by 2002:a67:9c1:: with SMTP id 184mr1654287vsj.41.1611597744795; Mon, 25 Jan 2021 10:02:24 -0800 (PST)
MIME-Version: 1.0
References: <34317129-8225-fb38-4ad3-e1b9ffed21fb@iecc.com> <9c84fa50-d23c-a794-fc62-09788ac383a9@mtcc.com> <CAHej_8mTaFo7aESFk4pHjbqbheriYPoAy6f+HhcE6ASVJSyViA@mail.gmail.com> <df867378-5da0-b912-2a0f-b2081d1f2437@mtcc.com> <CAHej_8kfCC1H89pRjgxXK=+BizJHFdKgnr7Gxh_2wWq8P7L-0Q@mail.gmail.com> <a94cb6c0-0a32-da8d-4bd5-9c7ab2866c82@mtcc.com> <CAH48ZfxkQ9g-gmBOPdDsxr4RDvXOi56EaX=aJVDbuL_g7kR+xQ@mail.gmail.com> <CAOZAAfOB93fpYRjwxgQNkG-ydVHLtvgUp0LLROvv-F-amJVy4w@mail.gmail.com> <b9e8da8e-f46a-49c0-4196-1d50ed94d526@mtcc.com> <CAOZAAfPh4kYq0yXhtP9BaPmtP_rc7L-0f=r3Ff_P3oxrhYqvtw@mail.gmail.com> <fd74120f-bfad-ef51-64d7-2f8ec4f00fab@mtcc.com> <CAL0qLwaPmMGR48EUhNkmZTozjoiTMnC6Rfmjdo9vLYD6ZhNoAw@mail.gmail.com> <CAOZAAfMcQ3HCrQAgKWeK-n2Acf+COK+E3HuCauh8g44KiWj=ng@mail.gmail.com> <25ea488b-e432-75c4-c57a-01d03308208c@mtcc.com>
In-Reply-To: <25ea488b-e432-75c4-c57a-01d03308208c@mtcc.com>
From: Seth Blank <seth@valimail.com>
Date: Mon, 25 Jan 2021 10:02:13 -0800
Message-ID: <CAOZAAfP5n15=Ez6_SFmkyDOyF=mpD8npZJmJujKP1vw322fGLg@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019887505b9bd57cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/71iYtEhZslfyPpmPOLZZKbGOrLI>
Subject: Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help
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: Mon, 25 Jan 2021 18:03:58 -0000

Michael, are you aware of anyone not following the guidance in the
document? This thread feels like we're discussing a non-issue. Aggregate
reports are already required to be authenticated and I'm unaware of anyone
sending failure reports, let along unauthenticated ones. Is the language
causing problems? Such problems have not been brought to the list, and
would be a good place to start if you want to build consensus.

The list seems to be digging in because no one has raised a use case that
shows a need to revisit the text. This was made worse by asserting that
reports must be authenticated, when the text already makes that clear.

It is likely in scope to discuss if the current text needs to be moved from
7.2.1.1 to 7.1, but let's please be careful to focus on operational
feedback and not personal opinions.

To be exceedingly clear: if this thread doesn't focus and come to
consensus quickly, then ticket #98 should be closed, unless a use case is
raised and supported by operational parties, that there is an issue here
requiring further clarification.

Ticket 99 is still in play, if and only if we decide on adding an HTTPS
transport for DMARC reports, of which historical consensus shows this is
unlikely. Let's press pause on that until the other discussion is
concluded, please.

Seth, as chair

On Mon, Jan 25, 2021 at 10:00 AM Michael Thomas <mike@mtcc.com> wrote:

> Issue #99 would need to be resolved if you want to use https as well.
> That's really why I brought up the entire issue. It's an easy fix for
> email, and not obvious how you fix it for https.
>
> Mike
> On 1/25/21 9:41 AM, Seth Blank wrote:
>
> Realized I think we're going in circles. Just posted text that is status
> quo that I believe already addresses Michael's concern.
>
> On Mon, Jan 25, 2021 at 9:38 AM Murray S. Kucherawy <superuser@gmail.com>
> wrote:
>
>> On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <mike@mtcc.com> wrote:
>>
>>> Why is this controversial? Seriously. What is controversial about saying
>>> that the a report should authenticate? The onus is on the people who say it
>>> does not to lay out the case for why it's not a problem, not me. #98 has a
>>> simple piece of text to remedy this. it's 2021. You don't use
>>> unauthenticated data if you can possibly help it.
>>>
>> I'm not taking a position at this point on the issue, but I think you
>> should expect that this will come up in external reviews.  If consensus is
>> to maintain the status quo, we might want to say so explicitly (and why)
>> rather than saying nothing, as the latter might be interpreted as it having
>> gotten no consideration at all.
>>
>> -MSK
>>
>
>
> --
> *Seth Blank* | VP, Standards and New Technologies
> *e:* seth@valimail.com
> *p:* 415.273.8818
>
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* seth@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.