Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 2/8/18 4:45 PM, Dave Crocker wrote:

On 2/8/2018 4:42 PM, Michael Thomas wrote:
Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.



The pandora's box is creating an incompatible new version.  All the 
rest is just engineering and operations tradeoffs.


Thankfully nobody's seriously talking about that from what i can tell, 
so this strikes me as so many angels on a pinhead.


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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 4:42 PM, Michael Thomas wrote:
Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.



The pandora's box is creating an incompatible new version.  All the rest 
is just engineering and operations tradeoffs.


d/

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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 2/8/18 12:32 PM, Mark Delany wrote:

I think this is the biggest flaw with the whole v= rationale. There is never
going to be a v=2 change that doesn't leave everyone continuing to
generate/validate a v=1 header. Is a new header by stealth better engineering
than formalizing a new header?

I dunno, it's not like there isn't precedent for this. oh say, like ipv4 
vs. ipv6?


Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.


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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John Levine]

In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write:
>After all, what are most senders going to do? They will not want their
>signatures to be suddenly unrecognized by 99% of the planet so they'll continue
>to generate a v=1 header and they will also want to reap the bennies of your
>fantastic SpamAssassin feature so they'll additionally generate a v=2 header.

In my application, the feature that requires v=2 is double signing,
i.e. this signature is valid only if there's also a signature from X.  It
was intended as a workaround for the DMARC mailing list problem

The idea is that in addition to your regular v=1 signature, you'd also
put a weak v=2 signature that requires re-signing by the mailing list.
If you don't use conditional signing (or something else subsequently
added that depends on v=2 semantics), then v=1 signatures are fine
forever.

The reason to make then both DKIM-Signature headers is that there is
code, some of which I've written, that looks for DKIM-Signature
headers in a message and calls a DKIM verifier library if it sees
them.  DKIM is slow, do you don't want to waste time verifying
messages with nothing to verify.  If you don't change the
DKIM-Signature header, all of this code keeps working when you upgrade
your DKIM library.  If you invent a new header, it doesn't.

>The end result is two DKIM-Signature headers with different versions for 
>decades
>to come. This will no doubt tweak some receiver is a negative way.

Only if their validators are broken.  I realize that's likely to be
the case now and then but I can't feel too sorry for them.

R's,
John
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Mark Delany]

> True, but not very interesting.  In my spamassassin example, the outside 
> code knows nothing about DKIM versions, it just sees a dkim-signature 
> header and sends it to the DKIM library.
> 
> The point of a v=2 flag is to ensure that old v=1 code doesn't

As a practical matter haven't you effectively invented a new header?

After all, what are most senders going to do? They will not want their
signatures to be suddenly unrecognized by 99% of the planet so they'll continue
to generate a v=1 header and they will also want to reap the bennies of your
fantastic SpamAssassin feature so they'll additionally generate a v=2 header.

The end result is two DKIM-Signature headers with different versions for decades
to come. This will no doubt tweak some receiver is a negative way.

I think this is the biggest flaw with the whole v= rationale. There is never
going to be a v=2 change that doesn't leave everyone continuing to
generate/validate a v=1 header. Is a new header by stealth better engineering
than formalizing a new header?


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

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

[John R. Levine]

 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.


Seems reasonable.  While we're picking nits, RFC 3864 says you can't register a 
field with a dot in it, might be worth a mention.


Also, according to the spec, #)*%;' is a valid field name, although I observe 
that every name in the field name registries is LDH.  Would it be worth a note 
saying that LDH names are likely to interoperate better?


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Dave Crocker]

On 2/8/2018 11:24 AM, Barry Leiba wrote:

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



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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Barry Leiba]

> 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...

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
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Pete Resnick]

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


On 2/8/2018 10:05 AM, Pete Resnick 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)

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

   field-name  =   1*ftext

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


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 
when you say:


4. If a spec defines a field-name using the %... construct, it has 
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.


5. That was most certainly /not/ what was 'intended' for field-name 
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
--
Pete Resnick 
Qualcomm Technologies, Inc. - +1 (858)651-4478
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Alessandro Vesely]

On Thu 08/Feb/2018 19:23:09 +0100 Dave Crocker wrote:
> On 2/8/2018 10:05 AM, Pete Resnick wrote:
>>
>> RFC 7405 is also useful along these lines.
> 
> If those modifications are used, sure.  If not, not so much.
> 
> 
>> 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)
> 
>    optional-field  =   field-name ":" unstructured CRLF
> 
>    field-name  =   1*ftext
> 
>    ftext   =   %d33-57 /  ; Printable US-ASCII
>    %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.
> 
> 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.

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
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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

[Barry Leiba]

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  wrote:
> On 2/8/2018 10:05 AM, Pete Resnick wrote:
>>
>>
>> RFC 7405 is also useful along these lines.
>
>
> If those modifications are used, sure.  If not, not so much.
>
>
>> 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)
>
>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/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

True, but not very interesting.  In my spamassassin example, the 
outside code knows nothing about DKIM versions, it just sees a 
dkim-signature header and sends it to the DKIM library.


Oh.  So v= doesn't dispatch to different code.



BTW, this topic tends to eventually produce a claim that the fact that 
the different versions share so much code justifies the versioning 
mechanism.


Except that code sharing happens in many circumstances that don't 
require conflating incompatible protocols and then using an internal 
demultiplexing switch.


The larger topic is the choice between high-level switching versus 
low-level, and the long-term costs of transition mechanisms.


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

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

[Dave Crocker]

On 2/8/2018 10:05 AM, Pete Resnick wrote:


RFC 7405 is also useful along these lines.


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


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)

   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/

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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 10:03 AM, John R. Levine wrote:
The code that knows to dispatch to v=2 can, just as easily, parse for 
the strings associated with the new features.


True, but not very interesting.  In my spamassassin example, the outside 
code knows nothing about DKIM versions, it just sees a dkim-signature 
header and sends it to the DKIM library.


Oh.  So v= doesn't dispatch to different code.



The point of a v=2 flag is to ensure that old v=1 code doesn't 
accidentally misinterpret new features. 


"Accidentally misinterpret new features" seems to be synonymous with not 
being upward compatible.  In other words, the new features make the new 
version incompatible with the old.  Hence, the new features define a new 
protocol.



 In my example, I made a
semantic change: in v=1 DKIM, verifiers ignore tags they don't 
understand.  In v=2, there's a new tag type that fails if a verifier 
can't handle it.


Change to basic semantics of the protocol.  Hence, new protocol.


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

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

[Pete Resnick]

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 
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.



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 

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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

The code that knows to dispatch to v=2 can, just as easily, parse for the 
strings associated with the new features.


True, but not very interesting.  In my spamassassin example, the outside 
code knows nothing about DKIM versions, it just sees a dkim-signature 
header and sends it to the DKIM library.


The point of a v=2 flag is to ensure that old v=1 code doesn't 
accidentally misinterpret new features.  In my example, I made a semantic 
change: in v=1 DKIM, verifiers ignore tags they don't understand.  In v=2, 
there's a new tag type that fails if a verifier can't handle it.  The new 
tags have new syntax that, in an ideal world, would make v=1 verifiers 
fail with a syntax error, but we all know that parse errors are often not 
well debugged.  I did look at a bunch of DKIM libraries and they all check 
for v=1 and fail if they don't find it.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 9:45 AM, John R. Levine wrote:

Huh?  v=1 code doesn't know what the new features would be.



Re-read what I wrote.

The code that knows to dispatch to v=2 can, just as easily, parse for 
the strings associated with the new features.


d/

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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

 the DKIM library.  If it passes a v=2 signature to a library that only
 knows about v=1, the library will say it's invalid, which isn't ideal but
 isn't wrong.


the code that tests for the v= parameter could, just as easily, check for the 
presence of the new features.


Huh?  v=1 code doesn't know what the new features would be.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 9:09 AM, John R. Levine wrote:
They seek to distinguish important differences in processing for what 
is claimed to be the /same/ protocol.


Except really they don't.


Except when they do.  I'm thinking, f'rinstance, that there is a bunch 
of code in things like Spamassassin that looks at headers and switches 
out to routines to do stuff with them.  There is nothing in Spamassassin 
that needs to care whether a DKIM signature is v=1 or v=2, that's all 
inside the DKIM library.  If it passes a v=2 signature to a library that 
only knows about v=1, the library will say it's invalid, which isn't 
ideal but isn't wrong.


the code that tests for the v= parameter could, just as easily, check 
for the presence of the new features.


d/


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

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

[Dave Crocker]

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 

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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[HANSEN, TONY L]

The ones I wrote certainly didn't require v=1 to come first. ;-)

But you're right: there's probably cause to be concerned.

Tony

On 2/8/18, 10:08 AM, "ietf-dkim on behalf of John R. Levine" 
 wrote:

> "v=1" doesn't have to come first.  It just usually does.  I think there 
was
> a version of RFC4871 that did that, but then when challenged we couldn't
> come up with a good reason to keep it that way.

I wonder how many DKIM libraries will accept a signature where it doesn't.  
  


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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Mark Delany]

On 08Feb18, John R. Levine allegedly wrote:
> On Thu, 8 Feb 2018, Mark Delany wrote:
> > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - 
> > apart
> > from exposing brittle parsers which mistakenly expect it to show up as the 
> > first
> > tag.
> 
> I had a draft that invented v=2, for headers with a tag syntax that is not 
> quite backward compatible with the current spec.  I realize that we could 
> change the header to DKIM-Improved-Signature but the change was small and 
> it smelled to me like the same header.

Yes, one can certainly contrive a situation in which they prefer a v=2 solution,
but as you say, the requirement can be just as easily satisfied in a number of
other ways too.

A new header is one as is the presence of a new tag and v= is a third. There are
other ways as well.

Given we're talking about standards, it's de rigueur that we end up with at
least three competing ways of achieving the same outcome without any guidance
whatsoever as to which mechanism to choose when and why.

Underlying all this of course is the assumption that programmers intuit the
possibility of change inherent in these non-essential mechanisms and code and
test accordingly. Now that's a goodun.


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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

They seek to distinguish important differences in processing for what is 
claimed to be the /same/ protocol.


Except really they don't.


Except when they do.  I'm thinking, f'rinstance, that there is a bunch of 
code in things like Spamassassin that looks at headers and switches out to 
routines to do stuff with them.  There is nothing in Spamassassin that 
needs to care whether a DKIM signature is v=1 or v=2, that's all inside 
the DKIM library.  If it passes a v=2 signature to a library that only 
knows about v=1, the library will say it's invalid, which isn't ideal but 
isn't wrong.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 8:52 AM, John R. Levine wrote:

On Thu, 8 Feb 2018, Mark Delany wrote:
Heh. I'm still waiting to hear a good reason as to why "v=" exists at 
all - apart
from exposing brittle parsers which mistakenly expect it to show up as 
the first

tag.


I had a draft that invented v=2, for headers with a tag syntax that is 
not quite backward compatible with the current spec.  I realize that we 
could change the header to DKIM-Improved-Signature but the change was 
small and it smelled to me like the same header.



What you realized goes to the heart of the reason we don't need version 
numbers.


The issue falls into the category of how to specify a processing fork. 
At each protocol layer, there is a mechanism for specifying which 
processing engine is appropriate for the next layer up.  Ethertype, 
Protocol ID, Port, etc.


Version numbers serve that purpose /within/ a protocol layer.

They seek to distinguish important differences in processing for what is 
claimed to be the /same/ protocol.


Except really they don't.

If modifications to a protocol are upward compatible, the the new 
features, themselves, self-identify and version numbers aren't needed. 
If no new features are present, you have the old 'version' of the 
protocol.  If new features are present, you have the new 'version'.


If modifications are /not/ upward compatible, you really have a new 
protocol.  Make a new entry in whatever forking mechanism was used to 
get to the previous version.  As you note, a new header-field would be 
appropriate here.


d/


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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

On Thu, 8 Feb 2018, Mark Delany wrote:

Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - 
apart
from exposing brittle parsers which mistakenly expect it to show up as the first
tag.


I had a draft that invented v=2, for headers with a tag syntax that is not 
quite backward compatible with the current spec.  I realize that we could 
change the header to DKIM-Improved-Signature but the change was small and 
it smelled to me like the same header.


See https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 8:17 AM, Mark Delany wrote:

"v=1" doesn't have to come first.  It just usually does.  I think there was
a version of RFC4871 that did that, but then when challenged we couldn't
come up with a good reason to keep it that way.


Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - 
apart
from exposing brittle parsers which mistakenly expect it to show up as the first
tag.



There appears to be a genetically-encoded belief in the value of version 
numbers, independent of the logic against it.  The belief is pervasive 
and seems to cross all technical cultures, experiential sets, and 
protocol layers.


d/


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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Mark Delany]

> "v=1" doesn't have to come first.  It just usually does.  I think there was
> a version of RFC4871 that did that, but then when challenged we couldn't
> come up with a good reason to keep it that way.

Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - 
apart
from exposing brittle parsers which mistakenly expect it to show up as the first
tag.

It's about as likely to change as "MIME-Version: 1.0", which is to say, never.


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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 8:05 AM, John R. Levine wrote:
I'm not saying any sensible person would do that, but as far as I can 
tell, that's what the spec says.



From a quick review of RFC 5322, I think you are correct.  I also 
believe (know) that this is not what has been intended for header field 
name specification, dating back to RFC 733.


That is, the capability you note is contrary to what I believe was 
intended in the RFC 5322 specification.  And deviation from iontent is 
the requirement for qualifying as an errata on an RFC.


I suggest you submit it.  It will be interesting to see the followup.

d/

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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

Header field name rules are in RFC 5322.  That deals with case sensitivity 
for field name strings.  Section 1.2.2 provides the basis for knowing whether 
a defined string is to be parsed in a case sensitive or insensitive manner.


That's right, and all of the fields defined in 5322 have case insensitive 
names, but as far as I can tell, I could define a header like this:


 pickle-header = %d80.111.99.107.108.101 ":" CFWS ( "dill" / "garlic" / 
"kimchee" )

So this is a pickle-header

 Pickle: dill

but this is not:

 pickle: garlic

I'm not saying any sensible person would do that, but as far as I can 
tell, that's what the spec says.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Dave Crocker]

On 2/8/2018 5:22 AM, John R. Levine wrote:
someone asked me about case sensitiveness of the header field name.  I 
looked

for an ABNF in RFC6376, but only found examples and informative notes.


Header field name rules are in RFC 5322.  That deals with case 
sensitivity for field name strings.  Section 1.2.2 provides the basis 
for knowing whether a defined string is to be parsed in a case sensitive 
or insensitive manner.



I was going to say that can't possibly be true, but it's true, there's 
no ABNF for the header.  So, for example, I don't know whether the v= 
field has to come first.  Send an erratum, we'll probably accept it as 
hold for update.


In RFC 6376, note Section 3.2 on tag lists.  The ABNF shows no 
sensitivity to ordering. (The linkage to DKIM-Signature is Section 3.5, 
first paragraph.)



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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

"v=1" doesn't have to come first.  It just usually does.  I think there was
a version of RFC4871 that did that, but then when challenged we couldn't
come up with a good reason to keep it that way.


I wonder how many DKIM libraries will accept a signature where it doesn't.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[Murray S. Kucherawy]

On Thu, Feb 8, 2018 at 5:22 AM, John R. Levine  wrote:

> someone asked me about case sensitiveness of the header field name.  I
>> looked
>> for an ABNF in RFC6376, but only found examples and informative notes.
>>
>
> I was going to say that can't possibly be true, but it's true, there's no
> ABNF for the header.  So, for example, I don't know whether the v= field
> has to come first.  Send an erratum, we'll probably accept it as hold for
> update.
>

"v=1" doesn't have to come first.  It just usually does.  I think there was
a version of RFC4871 that did that, but then when challenged we couldn't
come up with a good reason to keep it that way.

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

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

someone asked me about case sensitiveness of the header field name.  I looked
for an ABNF in RFC6376, but only found examples and informative notes.


I was going to say that can't possibly be true, but it's true, there's no 
ABNF for the header.  So, for example, I don't know whether the v= field 
has to come first.  Send an erratum, we'll probably accept it as hold for 
update.


By the way, all field names are case insensitive.  RFC 5322 doesn't say 
that explicitly, but the ABNF for the field names makes it pretty clear, 
On the other hand, RFC 5322 also says that field names can be any printing 
ASCII character so this is be a valid header.


$"%\)': plugh

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Where is the formal definition of DKIM-Signature?

[Alessandro Vesely]

Hi,

someone asked me about case sensitiveness of the header field name.  I looked
for an ABNF in RFC6376, but only found examples and informative notes.

Is that an error worth being reported?

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