Re: [dmarc-ietf] Authentication of reports

Michael Thomas <mike@mtcc.com> Wed, 20 January 2021 23:01 UTC

Return-Path: <mike@fresheez.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 0A7833A166E for <dmarc@ietfa.amsl.com>; Wed, 20 Jan 2021 15:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level:
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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=mtcc.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 OxAmtORpJ3qC for <dmarc@ietfa.amsl.com>; Wed, 20 Jan 2021 15:01:09 -0800 (PST)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 AF4C23A1632 for <dmarc@ietf.org>; Wed, 20 Jan 2021 15:01:02 -0800 (PST)
Received: by mail-pg1-x532.google.com with SMTP id c22so16229541pgg.13 for <dmarc@ietf.org>; Wed, 20 Jan 2021 15:01:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=HK2VUEdVyLbUF0/RP2lksbtroikA+3xndvLo6oHKmRI=; b=me1SvSSbn4uRd8O9hzf/+Ej2yCqU7mVLuqHTgWHzZKNFNb2O/iCjEjntEpDS3k9wjw cTS6MQJkkMQ+SjPesZgEzxxhPYqgFeeid9+q3tg/CSDCYZkDzgdj6tc4wRcbmPyMGic/ lC1FPuBL+7Bw84w/Ll0hwfC+dcel8z0uFUvLw60MxrOh+9xGwA0iUHC6Oxb5k5NYC8QS JToAsfwf70OpZDKr5rZOpzDcBQQLtGDJ7yy5eGAvxvw3zufFH22guwvWowpzi5ghlR6N PPqum4wx7zz0SucnFsLVG8pZsS85XHX6Oj5ftaIzIisJiUBpk7asw4YeT7fRsmWd3g77 1IYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=HK2VUEdVyLbUF0/RP2lksbtroikA+3xndvLo6oHKmRI=; b=VfDQEv/epEcUNRcX5APw7fGJihxBv3rZPvw3219rvWmZyDGR9wXzkpWXSVFYee/BUI 1Ggiy1j/k/HFqe1OWSOvJUZ4dc4M4zdGrfr4djS+9hqCWdP8uYZ0qBPLmtQAW9XwATUm SykwhX97nCb8Pr8eCmBfLy6EuJ2NeT7EaiIrLOy/TUzYthjFbleT1bYqI/PgPwhPVWG2 O7G7L4J0sHwYyBSUDK+S8s2tKMf1lkP5JhIDls2kXmjD2VUkyw5zVmyjwQZ/qJKAEq4J QiDaVFlkPeCh8/U1DbDBi5x3WMROxgUEyxr+P720tHOI6GgtvteWTzG+zoghCVFexopV olMg==
X-Gm-Message-State: AOAM532Wdg9LnwILvMNWjWZS6lE+uo5hJFUW7pawUnY7Zqjy05fTTe3F KazM0L991LiHLueqGc0jWSM5VnGGF48/0Q==
X-Google-Smtp-Source: ABdhPJycv9hPB2gcm4Avolnzo4oUcf9xTSZ81k2cQNy8iAR4anaDFszQrgoYBP3feRVI3mu5+o329A==
X-Received: by 2002:a63:1c13:: with SMTP id c19mr11349720pgc.359.1611183661498; Wed, 20 Jan 2021 15:01:01 -0800 (PST)
Received: from mike-mac.lan (107-182-35-22.volcanocom.com. [107.182.35.22]) by smtp.gmail.com with ESMTPSA id w184sm3542671pgb.71.2021.01.20.15.00.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Jan 2021 15:01:00 -0800 (PST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
References: <af4c2a23-4a55-9103-487c-72a394fa594f@mtcc.com> <CAL0qLwaAptLh9OFr4VdzyPV4KV1M8vbMSw8DWZCf4zqVbfaT5w@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <d2cb4ce1-a3d4-08a2-917d-0e1fdb71d400@mtcc.com>
Date: Wed, 20 Jan 2021 15:00:57 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwaAptLh9OFr4VdzyPV4KV1M8vbMSw8DWZCf4zqVbfaT5w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F4A978B212652DC0C5C27BD7"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/h53mMBZsmKnR3tzT8d7FH5Y4Cfo>
Subject: Re: [dmarc-ietf] Authentication of reports
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: Wed, 20 Jan 2021 23:01:17 -0000

On 1/20/21 2:56 PM, Murray S. Kucherawy wrote:
> On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>
>     I just scanned through DMARC and I couldn't find any security
>     requirements/mechanisms for the failure reports. I would think at the
>     very least the receiver consuming the reports ought make certain that
>     the report at the very least have either a valid DKIM signature or
>     a SPF
>     pass. Unauthenticated data is always the source of mischief, and I'm
>     sure that there have to be attacks that are possible with
>     unauthenticated reports. At the very least this should be a security
>     consideration, and most likely should have some normative language to
>     back it up.
>
>
> I thought the usual rules about when you should or shouldn't trust a 
> message ought to be applied, but I guess we never actually said that 
> in the document.  We certainly could.


DKIM is pretty nebulous about what it's results should used for, but as 
an authentication mechanism for another protocol it seem like it would 
be good say that explicitly. In this case it's a little more complicated 
since the thing processing the reports is almost certainly not at the 
boundary MTA verifying signatures.

>
>     Since I'm sort of new, it's been unclear to me whether whether
>     having a
>     new https transport mechanism is in scope or not -- it seems to
>     come up
>     pretty often -- but I'm not sure how people would propose to
>     authenticate the report sending client. That seems to me to be a
>     basic
>     security requirement for any new delivery method. The problem here is
>     there isn't a client certificate to determine where the report is
>     coming
>     from or any other identifying mechanism. An alternative might be
>     to DKIM
>     sign the report itself, but the long and short is that it would
>     need to
>     be addressed.
>
>
> As I recall DMARC originally (in its pre-RFC versions) did have 
> "https" as a supported scheme for "rua", but since nobody implemented 
> it during the years DMARC was in development, it got dropped before 
> publication.
>
>
So is it in scope or not? It's confusing if it's not because there seem 
to have been several open tickets about it.

Mike