Subject: [ietf-dkim] Fwd: [Technical Errata Reported] RFC6376 (4926)

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Feb 2017 07:33:08 -0800

G'day.

Looking for a community determination, here:  The DKIM spec's examples 
in A.2 and A.3 do not explicitly claim to be related to each other. 
However they do contain the same message, so that assuming a 
relationship seems pretty reasonable.

As such, calling the point raised in this Errata report an actual error 
is certainly not silly.  But I'm not sure it's correct, either.

Thoughts?

d/

-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC6376 (4926)
Date: Tue,  7 Feb 2017 07:17:12 -0800 (PST)
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked]
CC: [email-masked], [email-masked], 
text/[email-masked], charset=[email-masked]

The following errata report has been submitted for RFC6376,
"DomainKeys Identified Mail (DKIM) Signatures".

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

--------------------------------------
Type: Technical
Reported by: Simon Ser <[email-masked]>

Section: A.2, A.3

Original Text
-------------
From: Joe SixPack <[email-masked]>
To: Suzie Q <[email-masked]>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)

Corrected Text
--------------
From: Joe SixPack <[email-masked]>
To: Suzie Q <[email-masked]>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)

Notes
-----
The "simple" header canonicalization doesn't change the header fields in 
any way.

Folded header fields are missing one space of indentation (they have 5 
spaces instead of 6), which makes the verification fail. Note that the 
plain text version of the RFC adds a prefix of three spaces before each 
line of text, which must be ignored.

In section A.3, the indentation is changed again (5 spaces instead of 6 
+ the "b=" tag has 2 additional spaces of indentation).

Test cases:
- opendkim: 
https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
- go-dkim: https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9

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.
--------------------------------------
RFC6376 (draft-ietf-dkim-rfc4871bis-15)
--------------------------------------
Title               : DomainKeys Identified Mail (DKIM) Signatures
Publication Date    : September 2011
Author(s)           : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
Category            : DRAFT STANDARD
Source              : Domain Keys Identified Mail
Area                : Security
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Feb 2017 15:51:36 +0000

> is certainly not silly.  But I'm not sure it's correct, either.

Seems to me to maybe match the "hold for document update"
classification.

S.

> DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
>      c=simple/simple; q=dns/txt; i=[email-masked];
>      h=Received : From : To : Subject : Date : Message-ID;
>      bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
>      b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
>      4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
>      KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
>      4bmp/YzhwvcubU4=;
> Received: from client1.football.example.com  [192.0.2.1]
>      by submitserver.example.com with SUBMISSION;
>      Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
> Message-ID: <[email-masked]>
> 
> 
> Corrected Text
> --------------
> DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
>       c=simple/simple; q=dns/txt; i=[email-masked];
>       h=Received : From : To : Subject : Date : Message-ID;
>       bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
>       b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
>       4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
>       KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
>       4bmp/YzhwvcubU4=;
> Received: from client1.football.example.com  [192.0.2.1]
>       by submitserver.example.com with SUBMISSION;
>       Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
> Message-ID: <[email-masked]>
> 
> Notes
> -----
> - go-dkim:
> https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9
> 
> Instructions:
> -------------

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Feb 2017 12:06:10 -0500

Murray, Tony, or someone else: Can you independently check that these
examples need the extra space in order to be verified correctly?

Assuming they do, this errata report should be marked "Verified", but
the type should be changed to "Editorial", not "Technical".

Barry

On Tue, Feb 7, 2017 at 10:17 AM, RFC Errata System
<[email-masked]> wrote:
> The "simple" header canonicalization doesn't change the header fields in any way.
>
> Folded header fields are missing one space of indentation (they have 5 spaces instead of 6), which makes the verification fail. Note that the plain text version of the RFC adds a prefix of three spaces before each line of text, which must be ignored.
>
> In section A.3, the indentation is changed again (5 spaces instead of 6 + the "b=" tag has 2 additional spaces of indentation).
>
> Test cases:
> - opendkim: https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Feb 2017 10:25:38 -0800

> Murray did that for us a decade ago -- it's one of the test cases that opendkim uses.

Yes, but the point is: did Murray (or anyone) extract the text *from
the published RFC* and use that as input?  That is apparently what
Simon did, which resulted in this report.

> Hmmn.  It's really both, a technical error caused by an editorial change.

No: a Technical erratum is one where the spec actually says something
technically wrong, such that if you implemented according to the spec,
your implementation would be wrong.  Missing space characters in
examples == Editorial.

b

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Feb 2017 10:41:06 -0800

> your implementation would be wrong.  Missing space characters in

Hmmm.  I'm not worried about this error doing damage to the community, 
but since the formality of 'errata' is at issue in this exchange, I find 
the online guidance just ambiguous enough to be significant...

I suspect that "says something technically wrong" is meant to constrain 
things to the specification content, but that's not what the RFC-Editor 
definition says, nor is it clear to me that it should be that constrained.

The guidance at:

      https://www.rfc-editor.org/errata-definitions/

> Technical 	error in the technical content (Note that changes in the usage of RFC 2119 keywords are considered technical.)
>
> Editorial 	a spelling, grammar, punctuation, or syntax error that does not affect the technical meaning

The current error has technical import, since we are talking about a 
broken validation.

So, I'm not at all clear that this qualifies as only an 'Editorial' error.

Mumble.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Feb 2017 10:52:44 -0800

> definition says, nor is it clear to me that it should be that constrained.

I agree.  I think it mostly should, but that there should be judgment involved.

> The current error has technical import, since we are talking about a broken
> validation.
>

I don't see it that way.
I think there's a difference between an example that includes
"Reply-To" when it should have included "Subject" (that'd be a
technical error) and an example that includes "Sujbect" when it should
have included "Subject" (that'd be an editorial error)... even though
both of those errors might cause the signature not to verify.

I think an incorrect number of space characters is in the latter category.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Feb 2017 10:55:17 -0800

> I think there's a difference between an example that includes

So, I think I understand that view, which is why I said "ambiguous".

And the only reason I'm pursuing it, here, is that I think the 
determination of an erratum should not be so subjective.  I think the 
RFC Editor language defining categories should have criteria that are 
considerably more crisp.

d/

-- 

   Dave Crocker

---

From: Roland Turner <[email-masked]>
Date: Wed, 8 Feb 2017 09:52:09 +0800

> I think an incorrect number of space characters is in the latter category.

As a passing engineer who doesn't spend that much time spelunking IETF 
processes, a question that appears to be begged here is why the 
distinction matters. This is not immediately clear from any of the 
Status and Type of RFC Errata page 
<https://www.rfc-editor.org/errata-definitions/>, the How to Report 
Errata page <https://www.rfc-editor.org/how-to-report/>, or the FAQ 
<https://www.rfc-editor.org/faq/>. There is an important distinction 
when categorising changes during the preparation of an RFC (broader 
approval is required for technical changes), but this does not appear to 
apply to errata. Are you able to throw some light on this?

(On the question that Dave has raised:

  * I'd suggest that text which - in addition to being intended for
    human readers to understand - is intended for copy+paste into the
    input of an automated tool for interpretation by that tool but which
    contains typos contains what seems more like a technical than
    editorial error, even though the technical information being
    communicated to a human reader is essentially unchanged. This
    appears consistent with the first of the examples cited on the
    errata page; in that case anyone writing a validating parser and
    having it fail on the sample would quickly recognise the reversed
    order of the tags in the text, but it is nonetheless classified as
    technical.
  * I also note that the How to Report Errata page makes specific
    mention of what to do in ambiguous cases: "Tip: If the type is not
    clear, select Technical, and add your concern to the Notes."

)

- Roland

---

From: Barry Leiba <[email-masked]>
Date: Wed, 08 Feb 2017 02:05:30 +0000

Roland, your question is quite appropriate, and thanks for raising it.

At one level, I don't think it matters that much, so we're sort of arguing
minutiae.  But that's something Dave (and John) and I are often wont to do,
so...

My view is that the errata report type is there to alert viewers to what's
most important to note when you're implementing.  Do you need to look at
this to inform your implementation?   If you miss this one, will your
implementation suffer?

I think that's not the case here.  As I see it, the worst that will happen
is that you'll code, you'll test, and maybe you'll try pasting this example
in... and then you'll see a verification failure.  "Huh?", you'll say.  So
you'll check, and then you'll see the (maybe editorial) errata report, and
say, " Ah, that's OK, then," and move on.

Barry

On Tue, Feb 7, 2017 at 5:52 PM Roland Turner <[email-masked]>
wrote:

> processes, a question that appears to be begged here is why the distinction
> matters. This is not immediately clear from any of the Status and Type of
> RFC Errata page <https://www.rfc-editor.org/errata-definitions/>, the How
> to Report Errata page <https://www.rfc-editor.org/how-to-report/>, or the
> FAQ <https://www.rfc-editor.org/faq/>. There is an important distinction
>    - I'd suggest that text which - in addition to being intended for
>    human readers to understand - is intended for copy+paste into the input of
>    an automated tool for interpretation by that tool but which contains typos
>    contains what seems more like a technical than editorial error, even though
>    the technical information being communicated to a human reader is
>    essentially unchanged. This appears consistent with the first of the
>    examples cited on the errata page; in that case anyone writing a validating
>    parser and having it fail on the sample would quickly recognise the
>    reversed order of the tags in the text, but it is nonetheless classified as
>    technical.
>    - I also note that the How to Report Errata page makes specific
>    mention of what to do in ambiguous cases: "Tip: If the type is not clear,
>    select Technical, and add your concern to the Notes."
>
> )
>
>
> - Roland
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Feb 2017 18:32:46 -0800

On 2/7/2017 5:52 PM, Roland Turner wrote:
> <https://www.rfc-editor.org/faq/>.

<rant>

In recent years -- and by way of demonstrated some basic process 
problems, I'll note that I have no idea when the current constraints on 
the process were put in place -- the RFC errata process got moved into a 
very specialized place, to the exclusion of a number of useful 
functions.  It's not that what it does do isn't useful, it's that it has 
become idiosyncractic.  And, yeah, it does not appear to me that most 
folk know what it is and is not useful form.

</rant>

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Wed, 08 Feb 2017 03:04:32 +0000

When I was on the IESG, we had been talking with Heather and Sandy about
what to do about fixing up the whole errata system.   Not sure where that
is now.  It wasn't anyone's top priority at the time.

b

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Feb 2017 07:57:16 +0000

> is now.  It wasn't anyone's top priority at the time.

The RFC editor folks were too busy with the RFC format
fun. That's now much further along so I'd hope that it
becomes possible to address the errata system in the not
too distant future. If you care about that, it'd be no
harm to ping the IESG or an AD saying that you think it
is time to improve/fix the errata system.

Cheers,
S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2017 08:29:18 -0800

> Simon did, which resulted in this report.

It looks to me like this was some loss of precision in the transition from
RFC4871 to RFC6376.  The former has six spaces, and the latter has five.  I
very likely didn't change my test suite in between, or re-test the examples
in RFC6376 before it shipped.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Feb 2017 20:32:52 -0500

OK, so, Stephen:
This should definitely be closed out in some sort of accepted state.

Verified as Editorial is my preference.  Editorial because I don't
think it's a technical issue and it won't cause technical difficulties
in implementation.  Verified (not HFDU) because I think implementors
might use these examples to test their implementations, and will be
confused when they find examples that don't work (they're likely to
think they made implementation errors).

If you decide to leave it as Technical, then we should definitely go
with HFDU and *not* Verified.  The combination of Verified and
Technical implies a real technical error that would cause technically
incorrect implementations.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Feb 2017 18:24:00 -0800

> Verified as Editorial is my preference.  Editorial because I don't
...
> If you decide to leave it as Technical, then we should definitely go

Since I raised some fuss about this choice, let me be clear that I meant 
the fuss only in academic terms.  I don't think the difference matters, 
in this case, in terms of IETF process or actions.

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Feb 2017 10:55:20 +0000

On 14/02/17 01:32, Barry Leiba wrote:
> Verified as Editorial is my preference.

Done.

Cheers,
S.