Subject: [apps-discuss] [Technical Errata Reported] RFC7001 (4201)

From: RFC Errata System <[email-masked]>
Date: Mon, 15 Dec 2014 08:20:28 -0800 (PST)

The following errata report has been submitted for RFC7001,
"Message Header Field for Indicating Message Authentication Status".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7001&eid=4201

--------------------------------------
Type: Technical
Reported by: Stéphane Bortzmeyer <[email-masked]>

Section: C.5

Original Text
-------------
        Authentication-Results: example.com;
                  sender-id=fail header.from=example.com;
                  dkim=pass (good signature) header.d=example.com

Corrected Text
--------------
No idea

Notes
-----
The Sender-ID test is OK (header From:) but the DKIM one names a field
in the DKIM-Signature: header (d=). Isn't it a violation of section
2.2, which says 'if "ptype" is "header", this indicates from which header field the value being evaluated was extracted' Or is section 2.2 an insufficient description?

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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7001 (draft-ietf-appsawg-rfc5451bis-10)
--------------------------------------
Title               : Message Header Field for Indicating Message Authentication Status
Publication Date    : September 2013
Author(s)           : M. Kucherawy
Category            : PROPOSED STANDARD
Source              : Applications Area Working Group
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Mon, 15 Dec 2014 13:02:30 -0600

If you're not sure what's wrong or what to do about it, discussion on
apps-discuss would be best, before submitting an errata report.  Anyway,
Murray will respond to this, I'm sure.

Barry

On Monday, December 15, 2014, RFC Errata System <[email-masked]>
wrote:

> Reported by: Stéphane Bortzmeyer <[email-masked]
> <javascript:;>>
>
> Section: C.5
>
> Original Text
> -------------
> 2.2, which says 'if "ptype" is "header", this indicates from which header
> field the value being evaluated was extracted' Or is section 2.2 an
> insufficient description?
>
> Instructions:
> -------------

---

From: "John Levine" <[email-masked]>
Date: 16 Dec 2014 02:11:56 -0000

At the least, the wording in section 2.2 could use some work, and
we seem to have completely forgotten to document the property
subfields.

>2.2, which says 'if "ptype" is "header", this indicates from which header field the value being
>evaluated was extracted' Or is section 2.2 an insufficient description?

The relevant text in 2.2 says

     propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue
              ; an indication of which properties of the message
              ; were evaluated by the authentication scheme being
              ; applied to yield the reported result

The scheme uses a something from the header, idenfified by the property.

     property = special-smtp-verb / Keyword
             ; if "ptype" is "smtp", this indicates which [SMTP]
             ; command provided the value that was evaluated by the
             ; authentication scheme being applied; if "ptype" is
             ; "header", this indicates from which header field the
             ; value being evaluated was extracted; if "ptype" is
             ; "body", this indicates where in the message body
             ; a value being evaluated can be found (e.g., a specific
             ; offset into the message or a reference to a MIME part);
             ; if "ptype" is "policy", then this indicates the name
             ; of the policy that caused this header field to be
             ; added (see below)

Oops.  "Header field" in RFC 5322-ese indeed means which header, but
in this context it's intended to be scheme specific, as something
found in a header.

There's nothing in this document that actually explains what the
property keywords for the various authentication schemes are, other
that implicitly and incompletely in the examples.  Unless it's
lurking in some other document, I'm astonished that we missed that
both in 5321 and in 7001.  It's not always obvious; for DomainKeys,
the header.from is the domain name in the From: header, while for
DKIM, the header.xxx is the xxx subfield in the DKIM-Signature
header.  In SPF, smtp.mailfrom is the domain name in the MAIL FROM
command, and the undocumented smtp.helo is the argument to the HELO
or EHLO command.

The definition in 2.2 of special-smtp-verb should include "helo" in
addition to "mailfrom" and "rcptto" since SPF can validate that and
the code I adapted from Murray's libraries adds smtp.helo items to its
A-R headers.

R's,
John

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 Dec 2014 09:26:20 +0100

On Mon, Dec 15, 2014 at 01:02:30PM -0600,
 Barry Leiba <[email-masked]> wrote 
 a message of 142 lines which said:

> If you're not sure what's wrong or what to do about it, discussion
> on apps-discuss would be best, before submitting an errata report.

Two weeks before submitting the report, I emailed the RFC author.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Dec 2014 08:54:45 -0800

> Two weeks before submitting the report, I emailed the RFC author.

I received it but given the November and December holidays I had not
followed up on it since it didn't seem to be an urgent matter.

I agree with John's synopsis upthread, and will reply in more detail ASAP.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Dec 2014 19:47:14 -0000

>I agree with John's synopsis upthread, and will reply in more detail ASAP.

So what should we do about this?  I'm thinking that the gaps are large
enough that it'd be worth doing a new revision that includes the missing
stuff, replacing 7001.

R's,
John

PS: Yes. I'll help.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 18:25:33 -0500

> enough that it'd be worth doing a new revision that includes the missing

Happy to spin up a full update once the holidays are over.  I had been
planning to do that already, but the main issue I had was resolved with
RFC7410.

-MSK