Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax

ned+dmarc@mrochek.com Thu, 17 January 2019 12:59 UTC

Return-Path: <ned+dmarc@mrochek.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 6761F124BF6 for <dmarc@ietfa.amsl.com>; Thu, 17 Jan 2019 04:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level:
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 wUK88XeTCNfY for <dmarc@ietfa.amsl.com>; Thu, 17 Jan 2019 04:59:47 -0800 (PST)
Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5938912426E for <dmarc@ietf.org>; Thu, 17 Jan 2019 04:59:47 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R23UAVRQE800GT75@mauve.mrochek.com> for dmarc@ietf.org; Thu, 17 Jan 2019 04:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547729685; bh=7uxN12LiOpMVdv/ZcLND4Qq6s0Cy5XyaYtqrIVagsFc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=kjGbW8Q2XnG96qMKkS6kbSMTmmvS9mvFhqlkJYoI7ftLG3ymWKDfSG9RRugsXSBvs 9pb/uKd2E8F1YE3/H/YuSS5qKJw01lCsCUn23Tu+T1g0zBFWD7l8WpKNQAdMH2mV7i D2xxG06ihLWKU7OLYHdCIg6x2GJcxzswhVn/hwN0=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 17 Jan 2019 04:54:41 -0800 (PST)
From: ned+dmarc@mrochek.com
Cc: John Levine <johnl@taugh.com>, dmarc@ietf.org
Message-id: <01R23UAU5E3C00004L@mauve.mrochek.com>
Date: Thu, 17 Jan 2019 04:42:26 -0800 (PST)
In-reply-to: "Your message dated Wed, 16 Jan 2019 12:00:13 -0800" <8217a12c-385b-ab11-0453-b1be185f1701@gmail.com>
References: <20190116191824.0E64F200CC135A@ary.qy> <8217a12c-385b-ab11-0453-b1be185f1701@gmail.com>
To: Dave Crocker <dcrocker@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/x0idGkAfxcrnYAuj6WJphk1WErU>
Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax
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: Thu, 17 Jan 2019 12:59:48 -0000

> On 1/16/2019 11:18 AM, John Levine wrote:
> > Remember, that if your software rewrites an invalid record into a
> > correct one, you are trying to read the mind of the person who wrote
> > the misformed record.


> To emphasize a point you made earlier:  There are many, small
> adjustments that a receiver might make, with the intention of operating
> more robustly.  The current examples certainly quality as small and
> seemingly innocuous.  But the earlier point was that one deviation from
> the specification bodes ill for more important questions of conformance...

> If they didn't read this part carefully, why believe they read other
> parts more carefully?

The seemingly innocuous nature of the accomodation is only one of several
factors that need to be considered when deciding whether or not to implement
these things. Others include, but are not limited to:

(0) What are the worst case security considerations?

(1) Whether or not the misbehavior is widespread.

(2) Is the misbehavior likely to be corrected if you don't accomodate it?

(3) What wiil the effect of telling customers experiencing difficulties that
    it's Someone Else's Problem be?

(4) What is the long term impact on your code going to be?

All that said, in the present case this appears to be a nobrainer: Since the
correct behavior is to ignore malformed records, the security implications may
be significant, it is not widespread behavior, it's very likely to be
corrected, telling people that banks should get their security right seems like
an easy argument to make, and it's a bit of a wart on the code.

I'll also note that transmitters as well as receivers can play the
accomodatation game, with similar effects: What should be common cases
get turned into corner cases, and interoperability suffers as a result.

				Ned