Subject: [ietf-dkim] DKIM errata 1532 and 1596

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Jul 2010 11:02:05 -0400

There are two DKIM errata that we've still not dealt with, and we need
to sort them out and respond to them.  They can be found here:
   http://www.rfc-editor.org/errata_search.php?rfc=4871
...and are numbers 1532 and 1596.  Both were submitted by Tony -- so,
Tony, please review them and give us any further comments that'll help
us resolve them.

There are three applicable responses:

Verified: The item is correct, and it is important for those reading
RFC 4871 to pay attention to it.

Held for document update:  The item is correct, but it is not
immediately critical, and may be incorporated in the next revision of
the document.

Rejected: The item is incorrect or unnecessary, or needs to be
considered as a significant working-group item in future.

My comments on the two:

----------- 1532
What Tony says is not consistent with the WG consensus, which was NOT
to REQUIRE the presence of "v=DKIM1", and the text (Tony's "N/A"
notwithstanding) makes it clear that the absence of v= is interpreted
as "v=DKIM1".

He's correct, though, that the intent was for the DKIM key record to
be backward compatible with DK (RFC 4870, Historical), but that the g=
tag screws that up.  Perhaps what would be correct to say is this,
added after the g= paragraph and before its ABNF:

  Exception: if "g=" is specified with an empty value AND there is NO "v="
  specified at all, implementations MAY interpret this in the context of
  DomainKeys [RFC4870], treating it as DKIM's "g=*".

----------- 1596
1596 is trickier and more involved.  I think there's too much there to
make it "Verified" as is, and, while it's clear that Tony's right
about clarifying this point, it's not clear that it's been a real
problem for implementations.  I think we need more comment from Tony
about it, and then have a brief discussion in the working group.

-----------

I will probably add these to the agenda for Maastricht, but let's
start the discussion here, now.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 22 Jul 2010 10:29:19 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, July 22, 2010 8:02 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] DKIM errata 1532 and 1596
> 
> ----------- 1532

I like this compromise.

I concur that there's an ambiguity, but I also agree that it's not urgent.

My vote would be to construct the grammar or include remarks such that the actual value of "b=", or of any tag's value really, starts at the first character after "=" and ends at the first ";" or end-of-string, but with all unquoted unescaped whitespace removed.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 23 Jul 2010 15:43:58 -0700

I disagree with this proposed resolution.  I don't interpret backward 
compatibility as meaning that every DK selector must be usable with 
DKIM, but rather that it should be possible for the same selector record 
to be used by both DK and DKIM.

In any case, the change you're proposing introduces an ambiguity in the 
specification:  Under the circumstances cited, the verification result 
from DKIM is undefined.  That's a poor statement for a standard to make.

It's true that key records with empty g= values do contribute to 
verification failures; see

http://blogs.cisco.com/security/comments/common_errors_causing_dkim_verification_failures/

for a discussion of this.  The error we're talking about here is 
"inapplicable key".

As the discussion notes, there's an ESP out there that is giving their 
customers key records to publish that have empty g= values.  Yesterday, 
this single ESP accounted for 72% of all the Inapplicable Key errors we 
saw at Cisco.  I contacted this ESP last fall, and they have not 
corrected the problem.

There are lots of other syntax errors we see as well.  I don't think 
it's worth introducing an ambiguity in the specification to compensate 
for an easily correctable problem.  Do we next introduce a change in the 
spec to compensate for those that are publishing key records with 
extraneous backslashes?

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Jul 2010 19:50:13 -0700

Hi Jim,

I'm not clear on the objection here.  In particular, it seems to me Barry's proposed language lines up nicely with what you said starting "but rather".

As for the statement that the result would be undefined, I'm also unclear.  Are you saying two different implementers might do two different things because of that MAY?  If that's the case, then I think we're in some trouble because (for example) there's a MAY in the definition of "x=" that permits two results if the signature has expired.

-MSK
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jim Fenton [[email-masked]]
Sent: Friday, July 23, 2010 3:43 PM
To: [email-masked]
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM errata 1532 and 1596

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sat, 24 Jul 2010 10:20:58 -0700

> I'm not clear on the objection here.  In particular, it seems to me Barry's proposed language lines up nicely with what you said starting "but rather".

My point is that it's already possible for the same selector record to 
be used for both DK and DKIM.  Just leave the "g=;" out of the key 
record.  It's not necessary for DK in any case.

> As for the statement that the result would be undefined, I'm also unclear.  Are you saying two different implementers might do two different things because of that MAY?  If that's the case, then I…

I have never been clear on the value of x= (especially since it says 
it's not intended as an anti-replay defense), but you are correct that 
the spec is ambiguous as to whether a signature with an expired x= is 
valid or not.  I would lean in the direction of correcting that 
ambiguity, rather than creating a new one.

As everyone is probably tired of hearing me say, I'm all for looking for 
reasons to call a signature valid rather than invalid.  But there gets 
to be a point where it's really easy for the signer to fix the problem, 
and they haven't bothered to.  I don't have a lot of sympathy for 
signers who aren't willing to do even a tiny bit of diligence to make 
sure that their signatures are valid.  I don't think we should change 
the spec to accommodate them.

-Jim

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Jul 2010 11:05:22 +0100

On Thursday, July 22, 2010, Barry Leiba
<[email-masked]> wrote:
 [...]
> There are three applicable responses:
 [...]
> immediately critical, and may be incorporated in the next revision of

Barry, I don't think your description is quite correct. "Held for
update" is also used for something which is too big or too
controversial for "verified". It doesn't have to be correct. But of
course it is not obviously incorrect either.

Alexey