Subject: Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Feb 2018 09:30:26 -0800

While possibly a nice addition to the specification, including this ABNF 
rule does not correct an error in RFC 6376.

As for header-field name case sensitivity, that is the purview of RFC 
5322, not RFC 6376.

(FWIW, it does appear that there is an error in RFC 5322, since it does 
not enforce case insensitity in the syntax, although it specifies -- and 
intends -- it in the prose.)

d/

> 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/eid5260
> 
> --------------------------------------
> Type: Editorial
> Reported by: Ale <[email-masked]>
> 
> Section: 3.5
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> DKIM-Signature = "DKIM-Signature:" tag-list
> 
> Notes
> -----
> A formal definition is needed to make it explicit that this header field name is case insensitive, like all the other header field names.
> 
> 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
> 

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 8 Feb 2018 10:05:30 -0800

Dave,

Our respective ages are getting up there and my senility is setting in 
in earnest, so I have some sympathy along these lines, but given that 
you are the author of RFC 5234, you might want to check section 2.3 of 
that document:

    ABNF permits the specification of literal text strings directly,
    enclosed in quotation marks.  Hence:

          command     =  "command string"

    Literal text strings are interpreted as a concatenated set of
    printable characters.

    NOTE:

       ABNF strings are case insensitive and the character set for these
       strings is US-ASCII.

    Hence:

          rulename = "abc"

    and:

          rulename = "aBc"

    will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
    "ABC".

       To specify a rule that is case sensitive, specify the characters
       individually.

RFC 7405 is also useful along these lines.

So, no error in 5322. As for the erratum below, not having ABNF for the 
header field does seem like a miss, though I'm not sure it should be 
marked as more than "Hold for document update".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

On 8 Feb 2018, at 9:30, Dave Crocker wrote:

> While possibly a nice addition to the specification, including this 
> ABNF rule does not correct an error in RFC 6376.
>
>
> (FWIW, it does appear that there is an error in RFC 5322, since it 
> does not enforce case insensitity in the syntax, although it specifies 
> -- and intends -- it in the prose.)
>
> d/
>
>
>> A formal definition is needed to make it explicit that this header 
>> field name is case insensitive, like all the other header field 
>> names.
>>
>> Instructions:
>> -------------

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Feb 2018 10:23:09 -0800

> RFC 7405 is also useful along these lines.

If those modifications are used, sure.  If not, not so much.

> marked as more than "Hold for document update".

Consider:

1. RFC 5322 specifies ABNF for field names that is in terms of 'allowed' 
characters, but has no text constraining the method of defining the 
specific characters for specific header-field names.

2. Section 1.2.2 notes that "..." is case insensitive, but that the %... 
is inflexible (ie, sensitive.)

3. Nothing in the definition of optional-field requires using the "..." 
construct to define the header field name.  It merely defines what range 
of characteris allowed in a field-name.

    fields          =   *(trace
                   ...
                        optional-field)

    optional-field  =   field-name ":" unstructured CRLF

    field-name      =   1*ftext

    ftext           =   %d33-57 /          ; Printable US-ASCII
                        %d59-126           ;  characters not including
                                           ;  ":".

4. If a spec defines a field-name using the %... construct, it has 
effectively required case sensitivity in processing the field-name.

5. That was most certainly /not/ what was 'intended' for field-name 
parsing, going at least back to RFC 733. Violation of 'intent' is the 
criterion for an RFC erratum.

d/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Feb 2018 14:24:45 -0500

I believe the right solution to this, consistent with the intent of
how email header fields work, is to add a sentence (via errata) to RFC
5322 section 2.2 or section 3.6 -- or both -- somewhat like this:

OLD

   Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.  A
   field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.

NEW

   Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.  A
   field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.  In all cases, field names are interpreted as case-insensitive
   strings, so that, for example, "Subject", "SUBJECT", and "SuBjEcT"
   are considered to be the same field name.

END

Barry

On Thu, Feb 8, 2018 at 1:23 PM, Dave Crocker <[email-masked]> wrote:
>> header field does seem like a miss, though I'm not sure it should be marked
>> as more than "Hold for document update".
>
>
> Consider:
>
> characters, but has no text constraining the method of defining the specific
> characters for specific header-field names.
>
> 2. Section 1.2.2 notes that "..." is case insensitive, but that the %... is
> inflexible (ie, sensitive.)
>
> construct to define the header field name.  It merely defines what range of
> characteris allowed in a field-name.
>
>    fields          =   *(trace
>                   ...
>                        optional-field)
>
> 5. That was most certainly /not/ what was 'intended' for field-name parsing,
> going at least back to RFC 733. Violation of 'intent' is the criterion for
> an RFC erratum.
>
> d/
>
>
> --
> Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 8 Feb 2018 20:29:04 +0100

>                        %d59-126           ;  characters not including

The above section is referenced by RFC 3868, which in turn is referenced by the
IANA registry.  So, a case sensitive header field name is technically possible.

> 4. If a spec defines a field-name using the %... construct, it has effectively
> required case sensitivity in processing the field-name.
> 
> going at least back to RFC 733. Violation of 'intent' is the criterion for an
> RFC erratum.

Isn't that the difference between technical and editorial errors?  Since the
intent is clear, I reported the error as editorial.

The question arose because someone had DKIM-Signature changed to Dkim-Signature
by some (presumably DKIM-unaware) tool.  The user thought the culprit was my
signing filter, and reported a bug.  I told him to look somewhere else.  I
wanted to add that that change can be acceptable if canonicalization is
relaxed, but I was unable to point him to a line that explicitly stated or
implied case insensitivity.  I'd have to explain the intent maieutically,
which, in a standard, seems to leave something to be desired...

Ale

---

From: Pete Resnick <[email-masked]>
Date: Thu, 8 Feb 2018 11:25:06 -0800

On 8 Feb 2018, at 10:23, Dave Crocker wrote:

>> So, no error in 5322. As for the erratum below, not having ABNF for 
>> the header field does seem like a miss, though I'm not sure it should 
>> be marked as more than "Hold for document update".
>
> Consider:
>
> 1. RFC 5322 specifies ABNF for field names that is in terms of 
> 'allowed' characters, but has no text constraining the method of 
> defining the specific characters for specific header-field names.
>
> 2. Section 1.2.2 notes that "..." is case insensitive, but that the 
> %... is inflexible (ie, sensitive.)
>
> 3. Nothing in the definition of optional-field requires using the 
> "..." construct to define the header field name.  It merely defines 
> what range of characteris allowed in a field-name.
>
>    fields          =   *(trace
>                   ...
>                        optional-field)
>

Ah! I completely misunderstood: When you said, "RFC 5322 ... does not 
enforce case insensitity in the syntax", you were referring to 
optional-field. 5322 of course does enforce case-insensitivity in all of 
the other field names. My apologies.

That said, let's remember that, for better or worse (and in my 
aforementioned advancing age, I lean more toward worse every year), 5322 
does not have a multi-stage parser in the way that 733 or 822 did. So 

> effectively required case sensitivity in processing the field-name.

Well, sort of. I believe the expectation was that when syntactically 
processing a message, a field name would only match the field-name in 
optional-field if it failed to match any other defined field that the 
implementation understood, and therefore the semantic processing of the 
field would follow the instruction in 3.6.8:

    For the purposes of this specification, any optional field is
    uninterpreted.

The optional-field construct wasn't intended to define the syntactic 
processing of fields defined in other documents. I think it was assumed 
that other documents would syntactically extend 5322's syntax with new 
field names and implementations would update their parsers to include 
the new field names and therefore never process any recognized field 
name in a case-sensitive manner. That is, I believe the intent was to 
process any *recognized* field name in a case-insensitive manner.

> parsing, going at least back to RFC 733.

Given the difference in how messages are parsed between 733 and 5322, I 
think their respective intents are still being honored. However, I now 
do see your point.

> Violation of 'intent' is the criterion for an RFC erratum.

Of that there's no doubt.

pr

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Feb 2018 11:42:07 -0800

>     are considered to be the same field name.

wfm, although as a bit of belsts-and-suspenders, I'd also suggest in 
Section 3.6.8:

OLD:

    field-name      =   1*ftext

NEW:

    field-name      =   1*ftext
                        ; case insensitive, per sections 2.2 and 3.6

or somesuch.

d/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Feb 2018 14:42:05 -0500

> which, in a standard, seems to leave something to be desired...

I think it would be wrong to try to correct this in the DKIM spec:
It's not that DKIM is requiring that the header field name be
case-insensitive, but, rather, that email header field names are
case-insensitive.

Barry