[ietf-dkim] DKIM Interoperability Event notes

[Hector Santos]

Anything regarding t=y?

Based on SPF where this idea was borrowed from, it is basically a 100% 
ignored option.

It is clearly a threat entry point allowing anyone to try to create a 
DKIM signature and all they have to do is add t=y with the hope the 
receiver will ignore all fail validations.

--
HLS



Murray S. Kucherawy wrote:
> At the DKIM Interoperability Event in Dallas a couple of weeks ago I was 
> nominated as scribe during the discussions among the participants about 
> what parts of RFC4871 people found troublesome.  This is the 
> distillation of those notes.  They should be considered for possible 
> inclusion in a future "DKIM Errata" draft, if any.
> 
> 1. "s=" in key records: There is no explicit guidance about what to do 
> with clearly bogus values.  Examples given:
> 
>     s=*:email
>     s=foo:email:bar
> 
> The normative text covering "s=" doesn't say what to do if one of the 
> colon-separated words is a word not enumerated in the "currently defined 
> service types".  It also doesn't specify what to do with absurd values 
> like the first example.  The consensus is to ignore any colon-separated 
> value not recognized and only pay attention to "*" and "email" for DKIM 
> e-mail implementations.
> 
> 2. Empty bodies: Although the "simple" body canonicalization says 
> precisely what to do in the case of an empty message body, "relaxed" 
> does not.  The consensus is that the "relaxed" body canonicalization of 
> the null body is the null input, but it was conspicuous that "simple" 
> was explicit while "relaxed" was not.
> 
> 3. Multiple replies to TXT records: RFC4871 defines the handling of such 
> cases as "undefined", but it still came up in conversation several 
> times. Also noteworthy is that SSP has not yet added any discussion on 
> this topic.
> 
> 4. Empty local parts can be problematic: RFC4871 discusses the "g=" 
> (key) vs. "i=" (signature) comparison including the default for the 
> local-part to be used when "i=" is undefined, but it's possible a signer 
> could explicitly say "i=@example.com" and there's no way for "g=" to 
> match that other than using a wildcard (or the default).
> 
> 5. "x=" must be compared to a local time base instead of to "t=": I'm 
> not remembering the context about why I was asked to include this, so 
> maybe someone can refresh my memory here.
> 
> 6. "h=" (key) vs. "a=" (signature): One participant felt the requirement 
> to corellate these two values was not sufficiently normative.
> 
> 7. There is insufficient guidance about whether the domain in "i=" or 
> the domain in "d=" should be used when generating a domain reputation 
> query based on a DKIM signature verification.  At the end of this 
> discussion, participants were asked to think about this and try to 
> generate language for inclusion in later specifications to provide such 
> guidance.
> 
> -- 
> Murray S. Kucherawy ========================================= 
> msk at sendmail.com
> Principal Engineer           Sendmail, Inc.                Emeryville, 
> CA, USA
> (510) 594-5400                                         
> http://www.sendmail.com
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 


-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com