Subject: Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (3758)

From: Barry Leiba <[email-masked]>
Date: Sun, 20 Oct 2013 09:35:12 -0400

This one's right, of course: no one uses "v=DKIM1"; it's always "v=1".
 Authors, was this just left in from the "transition from DK" days?

Barry

On Sun, Oct 20, 2013 at 8:01 AM, RFC Errata System
<[email-masked]> wrote:
> 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=3758
>
> --------------------------------------
> Type: Technical
> Reported by: Majid Tajamolian & Nazilla Karkon <[email-masked]>
>
> Section: 3.6.1.
>
> Original Text
> -------------
> v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>       is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>       (without the quotes).  This tag MUST be the first tag in the
>       record.  Records beginning with a "v=" tag with any other value
>       MUST be discarded.  Note that Verifiers must do a string
>       comparison on this value; for example, "DKIM1" is not the same as
>       "DKIM1.0".
>
> Corrected Text
> --------------
> v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>       is "1").  If specified, this tag MUST be set to "1"
>       (without the quotes).  This tag MUST be the first tag in the
>       record.  Records beginning with a "v=" tag with any other value
>       MUST be discarded.  Note that Verifiers must do a string
>       comparison on this value; for example, "1" is not the same as
>       "1.0".
>
> Notes
> -----
> The "DKIM" prefix in the version field is unnecessary.
> for example the followings are snipped from an actual email via gmail.com:
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=20120113;
>         h=mime-version:from:date:message-id:subject:to:content-type;
>         bh=46j07/8gDec8jTto/znsrAKiXDj6YJ7Wa2DCoZuhwXc=;
>         b=h6SViP6DcHgPwydJD6aztqyKd0UmCN3SdwmqZd0uCHmqrprphjN8qQ8AnBDhbwDhAa
>          DfHIDS8RSegELKtzsp95u+DnIFg1uNhIukKVpGT+9MqxfCSAFk7WpMe2O/2gcLruilTe
>          MxkKJ29s64NGevYewKtI8s73xHmbzD1NFH9ugdow8i9E16kgQ+vAx56qvbFTBwdEEw8I
>          6Bteu3tXEsYYbU/9Akm2GXS+6PFiDSbv47u3EmhRQIOK3e8DvcobrpicjL7vUwBCpQuf
>          J/c+Acdq4GZQoMoG9imzku0K2o0w33CZ1xUR1bARJKCVaJfWeHiEMQ2OJ9A6ZtqpyK0z
>          1Ftg==
>
> Instructions:
> -------------
> This errata 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.
>
> --------------------------------------
> 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: Barry Leiba <[email-masked]>
Date: Sun, 20 Oct 2013 09:37:23 -0400

(Resending with Murray's new address.)

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 20 Oct 2013 09:43:12 -0400

No, wait: the reporter is confused, both about this errata report and
the companion one (h= vs a=).

Majid & Nazilla: You are looking at the section related to the key
records in DNS, and reading it as though it were about the signature
header in the message.

It's true that "v=1" is correct in the signature, and that in the
signature "h=" lists headers that are covered by the signature.  But
in the key record in dns, it's different, and RFC 6376 is correct.

Barry

---

From: Michael Thomas <[email-masked]>
Date: Sun, 20 Oct 2013 06:46:29 -0700

>   Authors, was this just left in from the "transition from DK" days?

Hmm, my implementation (the first) has it as DKIM1. That says that it's been
that way for a long time. Iirc, DK didn't have a version tag. I wouldn't 
count
on any sort of consistency here -- what it does say is that it's most likely
not being enforced though.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Oct 2013 15:55:15 -0400

On 10/20/2013 3:50 PM, Tony Hansen wrote:
> Perhaps, if this document is ever cracked open again, it would be useful
> to tag things better to make it painfully obvious what is being
> discussed. For example,
>
>      v= [Signature] Version (plain-text; REQUIRED) ...

Within the definition text, perhaps.

However we could develop a referential norm, independent of that, and 
then call for its use whenever docs are modified.  Something like the 
email header naming convention would make sense.

Hence:

   Signature.v =

   Key.h =

d/

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Oct 2013 16:21:12 -0400

On 10/20/2013 4:00 PM, Tony Hansen wrote:
> Use a "-" and I agree completely with this naming convention:
>
>      Signature-v =
>
>      Key-h =
>
> (Rulenames can use a hyphen, but not a period.)

was staying with the email header field notational form and hadn't 
thought to make it work in the bnf, but sure, why not.

d/

---

From: Tony Hansen <[email-masked]>
Date: Sun, 20 Oct 2013 15:50:46 -0400

> in the key record in dns, it's different, and RFC 6376 is correct.

I admit that I also got confused a few times while working on the DKIM
documents and keeping it straight as to which section was referring to
which set of arguments. Having them use different values and different
tags for items that were conceptually the same was an unfortunate aspect
of the history behind DKIM. If we had had no history to consider when we
first created DKIM, I think it would have been better to make things
match better, such as using a= for both specifications of algorithm, and
using v=DKIM1 for both version numbers.

But we didn't have that luxury, so we are stuck with our current situation.

   a= [Signature] The algorithm used to generate the signature (plain-text;
      REQUIRED).  ...
...
   v= [Key] Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "DKIM1"). 

   h= [Key] Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).

But this is unlikely to happen.

    Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Sun, 20 Oct 2013 16:00:16 -0400

Signature-v =

    Key-h =

    Tony

---

From: "Mark Delany" <[email-masked]>
Date: 20 Oct 2013 23:02:34 +0000

> aspect of the history behind DKIM.

Indded. And the inverse. That the same tag had different syntax or
semantics depending on location.

Originally there was a unified tag-space to avoid these risks. That
was easy back then as there was only 11 tags that covered policy, keys
and signature thus little risk of tag-space depletion even with single
character tags.

Perhaps ironically, around the time tag-space was dimensionally
expanded with versioning and multi-character tags, the principles
underlying the unified tag-space disappeared.

Anyway, as others have suggested, one solution is to put a tag-space
hierarchy into the spec or...

Alternatively, if you're a believer in versioning you could simply
bump the versions and re-assign tags. This way you get to feed two
birds with one cracker. Prove that versioning is useful and consign
this tag-space fuzziness to history!

Just kidding. Seems like Barry's later diagnosis is accurate thus if
any clarification is needed at all it can be bundled with other
errata.

Mark.