Re: [marf] [Technical Errata Reported] RFC6652 (6579)

Ned Freed <ned.freed@mrochek.com> Tue, 11 May 2021 16:02 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA203A1C91 for <marf@ietfa.amsl.com>; Tue, 11 May 2021 09:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 tPdjICbjMVse for <marf@ietfa.amsl.com>; Tue, 11 May 2021 09:01:58 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 179A83A1C92 for <marf@ietf.org>; Tue, 11 May 2021 09:01:57 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYWIZYCVKG009Y90@mauve.mrochek.com> for marf@ietf.org; Tue, 11 May 2021 08:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620748613; bh=grRyngXiZyl/AyyagwJjIMSB/DcKfW2mllyV3q3Z/mo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AhY3BUcOlA4CKLEGCUPma5H3up7nz2LcfMYzRUqBIGkMJRtGGGi1th2J5Z/DL+QJX oOUAg5ys+ziN+X4jnmf+RTx1rcprGeYJ+WbBaA2NylV29MkX8T6IsMsiRfqebP8wQ6 LIJt5E85Z7JbFuuUYGRTxMdyQJQEHRyKmgNHrcyc=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYVNHGP6CG0085YQ@mauve.mrochek.com>; Tue, 11 May 2021 08:56:48 -0700 (PDT)
Cc: scott@kitterman.com, superuser@gmail.com, francesca.palombini@ericsson.com, chaosben@gmail.com, rfc-editor@rfc-editor.org, marf@ietf.org
Message-id: <01RYWIZU1TYU0085YQ@mauve.mrochek.com>
Date: Tue, 11 May 2021 08:18:30 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 11 May 2021 07:51:12 -0700 (PDT)" <20210511145112.A5979F407E4@rfc-editor.org>
References: <20210511145112.A5979F407E4@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/marf/iIR0urPvqAWzRgkGe_WQ4wozXQM>
Subject: Re: [marf] [Technical Errata Reported] RFC6652 (6579)
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/marf/>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2021 16:02:03 -0000

This one is ... interesting, in a pedantic sort of way.

The current ABNF is clearly incorrect; the question is how best to fix it.

The simplest fix is:

  spf-rp-tag = "rp=" 1*3DIGIT 

This conforms to the ABNF used for similar percentage values 
in related specifications. For example RFC 7489 defines pct as:

  dmarc-percent   = "pct" *WSP "=" *WSP
                       1*3DIGIT

Even though the pct value is restricted in the text to the
same 0-100 range as is allowed here.

But this allows values outside the allowed range, as well as leading zeros. The
fix suggested in the report restricts things to the allowed range:

  spf-rp-tag = "rp=" "100" / 1*2DIGIT

But it doesn't deal with the leading zero issue. And it now disallows things
like "001" that were allowed before, and which do specify an in-range value.

If you also want to eliminate leading zeros, then you need something like:

  spf-rp-tag = "rp=" ("100" / ([%x31-39] DIGIT))

Of course there are other ways to do it, but I don't think there are
any that involve fewer terminals.

As to what implementations do, my guess is most call whatever integer parser
they have handy, and then check to see if the result is in range. This probably
means they are tolerant of leading zeros - although I guess it's faintly
possible that a value with a leading zero will be interpreted in base 8 - and
some probably allow a leading +/-.

And finally, there's the question of whether this is a correction or an update.
I think 1*3DIGIT clearly qualifies as a correction given that's what is in other
RFCs, but the more restrictive you get the closer you are to this being
an update.

Anyway, my recommendation is to go with 1*3DIGIT for now, although I don't
feel strongly about it.

				Ned

> The following errata report has been submitted for RFC6652,
> "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format".

> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6579

> --------------------------------------
> Type: Technical
> Reported by: Benjamin Schwarze <chaosben@gmail.com>

> Section: 3.

> Original Text
> -------------
> spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT

> Corrected Text
> --------------
> spf-rp-tag = "rp=" "100" / 1*2DIGIT

> Notes
> -----

> As explained in paragraph 3, the value of the "rp" modifier should be an
> integer value between 0 and 100. However, the specified abnf does not fit this
> requirement.

> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.

> --------------------------------------
> RFC6652 (draft-ietf-marf-spf-reporting-11)
> --------------------------------------
> Title               : Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
> Publication Date    : June 2012
> Author(s)           : S. Kitterman
> Category            : PROPOSED STANDARD
> Source              : Messaging Abuse Reporting Format
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

> _______________________________________________
> marf mailing list
> marf@ietf.org
> https://www.ietf.org/mailman/listinfo/marf