Subject: [ietf-dkim] Issue 1579: ADSP result set, New issue: ADSP status codes

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Jul 2008 13:25:51 +0100

Issue description: https://rt.psg.com/Ticket/Display.html?id=1579

This cropped up as part of a different thread [1] related to
a different (now closed) issue.

The suggestion (I think) is to define three possible
ADSP results (open/closed/locked).

ssp-04 doesn't do that - it lists 4 possible results,
but doesn't give those specific names.

The issue was raised on May 30, but there's been
no support for the change on the list since then.

If there's no further discussion, I'll ask Eliot
to close this on on July 11.

S.

[1] http://mipassoc.org/pipermail/ietf-dkim/2008q2/010279.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Jul 2008 04:39:56 +0200

> ADSP results (open/closed/locked).

Yeah, my part in that was mostly focussed on "there is
no worse name than 'discradable', therefore 'locked' 
might be better".

> but doesn't give those specific names.

 [3.3]
| All messages from this domain are signed and discardable.

Even if you stick to "discardable" that is certainly not
what you want.  Maybe [...] "are either signed or" [...}

 [4.2.1]
|  adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS
|                     ("unknown" / "all" / "discardable")

<digression>
 Never, under no circumstances, allow more than one FWS,
 a single optional [FWS] is bad enough in DNS.  More than
 one introduces the miracles of "apparently empty lines"
 consisting entirely of "semantically significant white
 space".  

 Submitted as 4871 erratum - normally I'd say "editorial",
 but the other reported DKIM ABNF nits say "technical".
</digression>

ssp-04 still says "discardable", and maybe it passes IETF
review for status "experimental".  But spp-04 clearly says
"standards track", and does not mention Resent-* anywhere.

For receivers rejecting suspicious mails the draft should
note the relevant SMTP reply and extended error code with
a reference to RFC 5248.  

 Frank

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 05 Jul 2008 15:37:34 +0100

Frank,

I'm not clear if you're saying that this remains an open
issue or not or whether you're raising new issues or what.
Can you clarify?

Thanks,
Stephen.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 16:31:48 +0200

> issue or not or whether you're raising new issues or what.

1: One new issue (trivial unless we forget it), fix the *FWS

2: Two old issues, "discardable" + status code.  The latter
   is simple, a reference to RFC 5248 and a recommendation 
   what receivers are supposed to do when they reject ADSP-
   "discardable" mail.

3: One major issue, "discardable" without in depth discussion
   of "false positive" wrt Resent-* scenarios is a show stopper
   for ADSP, it could delete legit 2822upd Resent-messages.

   All "process failure" and legal problems you can think of
   apply.  Slight variation of a bitter joke on the general
   list, ADSP would need a "no problem" statement from the
   rfc822 list written in an appropriate medium such as
   blood if you want to keep "discardable".

Maybe split off the minor points (1) + (2), e.g., (1) could
be tracked in lieu of the former FWS-issue, apparently folks
want FWS in DNS because DKIM also has it, and while it makes 
no sense it could be worse to get a different story in ADSP.
But *FWS is flat out wrong (reported as DKIM erratum).

For (2) if all else "FAILs" (pun) copy a relevant statement
from RFC 4408 with a reference to the new RFC 5248.

I hope that's clearer now, the hard case is (3).  It's about
folks using Resent-* and touching the original header fields
for some reason (i.e. breaking the ADSP protected signature).

 Frank

---

From: John Levine <[email-masked]>
Date: 6 Jul 2008 15:30:16 -0000

>1: One new issue (trivial unless we forget it), fix the *FWS

I agree that in retrospect, DKIM should have used WSP rather than FWS
in the DNS records.  But it says FWS, existing code really does FWS,
and it makes sense to me for ADSP to be consistent.

>   what receivers are supposed to do when they reject ADSP-

Mission creep.  DKIM and ADSP don't say anything about SMTP sessions.
They are equally applicable if mail is delivered by being spooled onto
a thumb drive and delivered by courier.

>   for ADSP, it could delete legit 2822upd Resent-messages.

Huh?  There's an unlimited number of reasonable message
transformations that can break DKIM signatures.  Why does this one
require special discussion while, say, recoding MIME parts from base64
to QP doesn't?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 20:22:00 +0200

John Levine wrote:
 
> I agree that in retrospect, DKIM should have used WSP
> rather than FWS in the DNS records.  But it says FWS,
> existing code really does FWS, and it makes sense to
> me for ADSP to be consistent.

Yes, that was what I meant when I wrote:

| apparently folks want FWS in DNS because DKIM also has
| it, and while it makes no sense it could be worse to
| get a different story in ADSP.
| But *FWS is flat out wrong (reported as DKIM erratum).

See <http://rfc-editor.org/errata_search.php?eid=1461>

 [reject vs. discard] 
> Mission creep.

Well, I'd know how to kill the draft post-approval with
what you consider as "mission creep".  Resent-* is going
to stay, and ADSP "discardable" is a frontal assault on
Resent-* cases managing to spoil the From-signature(s).

At the very minimum you need to have the reason why any
Resent-* scenario destroying signatures is "broken by 
design" on public record.  Maybe put it in the security
considerations.  I won't let 2822upd say A and ADSP say
not A.  See RFC 5016 chapter 4.3, we saw this coming...

> DKIM and ADSP don't say anything about SMTP sessions.

Similarly SPF does not tell receivers that they should
reject FAIL, it only tells them to check SPF at a place
where that is the only plausible decision, and how to
do it if they decide to reject FAIL.

The complete concept of "discard" is utter dubious for a
non-zero chance of "false positives".  For mailing list
problems it's solved by definition, so this is no "false
positive" - it is only a harsh self-restriction on the
side of the author domain, they are not forced to state
"dkim=discardable" if they don't like the consequences.

But for Resent-* the author domain has no authority over
resenders.  Everybody is entitled to resend mail, years
after it arrived.  ADSP claiming that such legit Resent-*
scenarios are "discardable" is a process failure.  This
means "DO NOT PUBLISH", not "mission creep".

 Frank

---

From: John Levine <[email-masked]>
Date: 6 Jul 2008 18:58:40 -0000

>| But *FWS is flat out wrong (reported as DKIM erratum).

Ah, you want [FWS] rather than *FWS.

>See <http://rfc-editor.org/errata_search.php?eid=1461>

I see it, but I also see that nobody has confirmed it.  If the DKIM
authors agree it's a mistake, then we should change it.  Otherwise,
consistency wins.

>means "DO NOT PUBLISH", not "mission creep".

Um, I think this might be a good time to review what DKIM is and
isn't.  It's intended to protect messages in transit, not in archives.
Umpteen years later, with or without Resent headers, the signing key
is unlikely still to be in the DNS, so any process that depends on
verifying DKIM on old messages won't work.  ADSP doesn't change that.

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 6 Jul 2008 22:24:42 +0200

John Levine wrote:

> I also see that nobody has confirmed it.

After three days that would be rush.  A missing comma in
RFC 2045 reported by a co-author 44 months ago is still
not "confirmed".

> If the DKIM authors agree it's a mistake, then we should
> change it.  Otherwise, consistency wins.

As noted in the erratum this is consistent with the rest
of this section in RFC 4871, with the FWS rationale in 
RFC 4871 chapter 2.3, and with MUSTard in 2822 + 2822upd.

There is no such thing as "x" *FWS "y", this would allow:

x<CRLF>
<SP><CRLF>
<SP><CRLF>
<SP><CRLF>
<SP>y

But that also matches "x" obs-FWS "y", and so there can't
be a valid reason to talk about *FWS in conjunction with
RFC 4871 chapter 2.3.  

A similar RFC 2822 FWS erratum reported 30 months ago is
also not yet "confirmed", it was simply fixed in 2822upd.

> Um, I think this might be a good time to review what DKIM
> is and isn't.  It's intended to protect messages in transit,
> not in archives.  Umpteen years later, with or without
> Resent headers, the signing key is unlikely still to be
> in the DNS, so any process that depends on verifying DKIM
> on old messages won't work.  ADSP doesn't change that.

If the ADSP draft somewhere states that adding Resent-* in
some legit or malicious ways is intended to bypass all ADSP
processing I missed it:  I only looked for strings beginning
with "resent-".  

Next radical attempt, I now read the security considerations
from scratch, nothing.  Following the pointer to RFC 4686 =>
nothing about "discardable" attacks on legit Resent- mails.

 Frank

---

From: John Levine <[email-masked]>
Date: 6 Jul 2008 21:46:24 -0000

>processing I missed it:  I only looked for strings beginning

There aren't any, since as you perfectly well know, the only header
that ADSP looks at is From:. Adding Resent-* headers has no effect
unless the DKIM signature is set to break when they're added.

I have to say this argument makes no sense to me.  Nothing about DKIM
works if you take an ancient message and remail it, since the keys are
not long-lived.  Furthermore, nothing in section 3.6.6 of 2822 or
2822bis says that adding Resent- headers is supposed to make people
handle mail in any particular way.

I suppose that "discardable" makes it a little more explicit that
people might treat such mail unfavorably, but it shouldn't come as a
big surprise that mail with stale or broken signatures is less likely
to show up in people's inboxes, with or without Resent-* headers and
with or without ADSP.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 07 Jul 2008 12:08:41 +0100

> no support for the change on the list since then.

I think the lack of support is because Doug's suggested notational change  
was part of a larger proposal, the rest of which noone was interested in.

But I rather like it as a pure improvement in terminology, so take this as  
a rather limp

+1

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 03:59:13 +0200

John Levine wrote:

> Adding Resent-* headers has no effect unless the DKIM signature
> is set to break when they're added.

Depends on what resenders do, e.g., modifying the Subject might
not fly.  Not permitted in 2822upd, but if an MDA adds "missing"
header fields they would then be a part of an otherwise perfect
2822upd Resent-* mail.

The Resent-* concept in RFC 822 is slightly different from the
2822upd concept, it treats "resending" as "forwarding".  I'd be
not surprised if MUAs supporting the 822-variant "update" other
header fields.

> Nothing about DKIM works if you take an ancient message and
> remail it, since the keys are not long-lived.

DKIM does not say that old signatures indicate discardable mail,
that's an ADSP disease.  Resenders are not necessarily involved
in DKIM at all.  They follow RFC 822, 4406, or 2822upd as good
as they can (maybe not simultaneously, the RFCs are incompatible
wrt some Resent-* details).

> I suppose that "discardable" makes it a little more explicit 
> that people might treat such mail unfavorably

As long as "treat unfavourably" boils down to "reject" it's fine,
"the sender can then make another plan", as EAI put it, it works
also for resenders.

But if "treat unfavourably" results in "discard" a mail is lost.
The name "discardable" suggests precisely that, "discard", with
legit mail vanishing in some black ADSP hole.

> it shouldn't come as a big surprise that mail with stale or
> broken signatures is less likely to show up in people's inboxes,
> with or without Resent-* headers and with or without ADSP.

For folks publishing a "discardable" policy it's what they asked
for, no problem.  But the draft does not mention that this also
affects innocent bystanders minding their own Resent-* business,
not at all interested in ADSP.

The name "discardable" is wrong.  And independent of the name not
mentioning Resent-* of "ancient" mail at all is also wrong.  Here
"ancient" could mean anything down to "yesterday".

RFC 4408 has section 9.3.  ADSP needs a *long* section 6.4, where
you can bury "resent ancient mail" under appropriate weasel words.  

 Frank