Subject: Re: [ietf-dkim] Output summary - Communicating Results

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 03:03:33 -0400

I'm starting a separate thread for the considered intro text discussion.

This response attempts to provide DKIM in-scope justification why two 
additional outputs should be part of a more "DKIM Complete Output" 
summary.

Murray S. Kucherawy wrote:

> That's probably true, but that is also completely different 
> from necessitating a change to the mandatory output.

Maybe this is about "DKIM Output Complete " rather to redundant burn 
in of what is mandatory.  Everyone already knows SDID is a mandatory 
output for trust based assessor.  The proposed text did say other 
outputs are possible, but I believe there is a minimal set of in-scope 
outputs that we know are useful bits of information because of what 
implementators are showing.

Let me use ODID (Originating Domain Identity) to help describe this.

I believe we have four minimal in-scope outputs that is consistent 
with the DKIM Service Architecture (RFC5585),  Identity Assessor 
Layers and Reporting recommendations.

    RCODE  result code)
    SDID   d=, described as a MUST for (trust) assessors
    AUID   i=, described as a MAY for assessors
    ODID   Domain part of From: address.

There is nothing new here and I believe satisfies IETF protocol 
design, bis work and DS considerations. It reflects current 
implementations, doesn't change code and definitely helps future 
implementors.

Justifying ODID is simple:

The ODID is an optional requirement in the complete software 
engineering design described in the DKIM Service Architecture [RFC5585].

While ODID is an optional consideration for implementors to support 
the Checking Signing Practices (ADSP) module, it is nonetheless part 
of the RFC described DKIM Service Architecture.  Therefore for 
RFC4871bis to be consistent with RFC5585, it needs to explicitly 
expose the ODID as part of the DKIM Complete Output.

Justifying AUID is simple as well.

Dave's MLM shows an A-R (using Thomas's list post):

  Authentication-Results: sbh17.songbird.com;
    dkim=pass (1024-bit key) header.i=[email-masked]

It only shows the AUID. This suggest existing implementations are 
using the DKIM recommended A-R reporting method and needs the AUID as 
part of a DKIM Complete Outputs.

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

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

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 03:34:21 -0400

Murray S. Kucherawy wrote:
>> -----Original Message-----

>> But what it did most of for me (yesterday) was highlight the confusion
>> with AUID with the lack of an official DKIM label for an Originating
>> Domain Identity.  I guess I was moving forward the past year with
>> integrating DKIM into our mail products and I see now I was mistakenly
>> labeling the AUID as the FROM domain when its not officially defined
>> as the From domain.
> 
> That's unfortunate, but it's also the first case I've heard 
> of someone mistaking the AUID for the From: field.

To be more precise, may erroneous labeling of AUID as the author or 
user DOMAIN in the From: address for ADSP purposes.

Its been an ongoing debate with what AUID (i=) is. Just see the recent 
threads with Fenton's proposal to remove it and some suggested to keep 
with refinements like i= should be the From address.

This is why Barry's message is important here (got to find it) because 
if I can correctly recall, he showed both CON and PRO logic on how/why 
an undefined i= can be assumed to be the From and and the From.domain 
for ADSP purposes.

>>    3.x  Originating Domain Identity (ODID)
>>
>>    The ODID is the domain part of the From: address.  This identity
>>    MAY be considered as an output communicated to an advanced
>>    Identity Assessor module.
> 
> We already have a name for that: "RFC5322.From".  We don't need a 
> new name for something old.

If we want to say From.Domain is an identity, fine by me.

> I don't see any ambiguity here that needs fixing, unless there 
> are lots of people that want to come forward now and admit 
> they had the same misunderstanding you did.

There is plenty of archive evidence old and new regarding i= (AUID) 
ambiguity, including whether it should be a USER identity as the 
definition ambiguously says "Agent or User."

Who/What is an Agent? Undefined?

Who is the User?  I presume the RFC5322.From?  No?

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 03:38:51 -0400

John R. Levine wrote:
>> What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
> 
> Oh, that.  Replace all of sec 9.1 with:
> 
>   "As noted in Section 4.4.5, use of the l= tag enables a variety of
>   attacks in which added content can partially or completely changes the
>   recipient's view of the message."
> 
> I don't think we actually understand all the ways that l= allows you to 
> shoot yourself in the foot, so I would prefer not to give the impression 
> that if people avoid a few cases we describe, they're safe.

+1

Unfortunately, if you do a global search in the document where l= is 
mentioned, you will see sentences with inferences for an expectation 
it is present and/or should be added.  These sentences need to be 
reworded to indicate it is an option and not an expectation.

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 03:47:31 -0400

Murray S. Kucherawy wrote:

>> How will you state it?
> 
> How about:
> 
> 1.  Introduction
> 
> [...]
> 
> 1.1.  DKIM Architecture Documents
> 
> Readers are advised to be familiar with the material in [RFC4686] 
> and [RFC5585] and [RFC5863], which respectively provide the background 
> for the development of DKIM, an overview of the service, and deployment 
> and operations guidance and advice.
> 
> 1.2.  Signing Identity
> 
> [...]

+1 Perfect.  Very good!  I like it!

Now if we can just be more "DKIM Output Complete" and be z-order 
compatible with the excellent section 1.1, I think I can die and rest 
in peace. :)

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 04:38:18 -0400

Dave CROCKER wrote:

> In other words, DKIM has nothing to do with the rfc5321.From field, and 
> therefore it is entirely inappropriate -- that is, out of scope -- for 
> the specification to suggest dealing with it.
> 
> At least, please show working group rough consensus support for doing 
> what you suggest.
> 

Dave,

All I am trying to do is show the inconsistencies in RFC4871bbis not 
matching current implementation needs and it is incomplete in what 
RFC5585 describes.

I didn't write RFC5585 but if I did, I would not have added the 
Checking Signing Practice and titled it as "DKIM Service Architecture" 
because the concept was removed from DKIM.  But you did and the 
Deployment Guide has an entire section on ADSP.  The archive is my 
evidence, I have stated if you don't want ADSP then don't reference it 
any DKIM related document.

But it was done in in the Deployments Guide and explicitly added as 
part of the DKIM Service Architecture, not stated it is an "Extension" 
or any one shown to be not part of the architecture.  Its right there 
as a large part of the software engineering design.  What do you 
expect people to think?

So I suggest reasonable people taking this documents will clearly see 
policy, signing practice, adsp or whatever you wish to call, its part 
of the DKIM design and architectural consideration and RFC4871bis does 
not prepare anyone for that DKIM architecture design.

IETF BIS work should be, at least I thought it was, about codifying 
current implementation and they match RFC5585, not RFC4871bis.  Is 
that a problem? I think so.  You seem to think not.

All I am saying is with the window of opportunity we have now, connect 
the dots and be consistent with the RFC described DKIM Service 
architecture.

Finally, you keep saying:

     "DKIM has nothing to do with the rfc5321.From field"

(Well, I think you meant RFC5322.From. Right?)

This is not technically correct.

1) It is the only single requirement for binding to the signature and 
there again, the archive evidence will show where I have stated on 
many occasions if we want the above statement to be true, then we need 
to relax the specs to remove this single mandatory binding signature 
requirement.

2) The binding of 5322.From is inherently associated with the SDID 
responsibility claim for the bits that are signed. So for anyone to 
use SDID trust, it is to both technically and ergonomically (UI) claim 
the author is trusted whether or not the signer had any association 
with the author or not.

Again, its about protocol consistency.  So maybe I should ask the 
chairs for:

          "Consensus needs to be reevaluated"
-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 01 May 2011 11:05:18 +0200

> that if people avoid a few cases we describe, they're safe.

-1, I agree we don't know all the ways DKIM can be fooled.  Neither we
actually saw real attacks in the wild.  We don't even state how to
react to multiple Froms.  Presumably, the wider the DKIM deployment,
the more we'll learn on handling attacks.  However, hiding the few
things we know doesn't seem to be a good start toward such watchful
cooperative deployment.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 1 May 2011 08:13:20 -0400

> things we know doesn't seem to be a good start toward such watchful

The message should be don't use l= if you care about your signature.

I don't think we yet have consensus to take out l= but it is quite clear 
that the problems it causes are far greater than whatever problems it 
might solve.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 01 May 2011 07:58:38 -0700

Dave CROCKER wrote:
> 
> On 4/30/2011 9:10 PM, Hector Santos wrote:
>> So perhaps to help shut down this ambiguity we should add a DKIM
>> terminology to clearly separate it from AUID.
>>
> Oh heck, let's just declare that the DKIM Signing module MAY output anything it 
> wants.  

That's what 4871 did. Manifestly it worked just fine. We had a tremendous number
of interoperable implementations. The procrustean insistence that there be a
single "output" has not helped interoperability one iota.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 May 2011 10:15:34 -0700

On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
> I'd like to leave in MIME and HTML exploits as examples if people agree that wouldn't be harmful, such as this updated text in 4.4.5:
>
>                       <t>INFORMATIVE IMPLEMENTATION NOTE: Using body length
>                          limits enables an attack in which an attacker modifies a
>                          message to include content that solely benefits the
>                          attacker. It is possible for the appended content to
>                          completely replace the original content in the end
>                          recipient's eyes, such as via alterations to the MIME
>                          structure or exploiting lax HTML parsing in the MUA,
>                          and to defeat duplicate message detection algorithms.
>                          To avoid this attack, signers should be wary of using
>                          this tag, and verifiers might wish to ignore the tag,
>                          {DKIM 2} perhaps based on other criteria.</t>
>
> I'm worried that without this, a neophyte won't see what the attack is.

+1

d/
-- 

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

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 17:29:52 -0400

> things we know doesn't seem to be a good start toward such watchful

It appears to me, the current practical use case for l= is for systems 
like an non-DKIM aware MLM that is not stripping and replacing 
signatures. The idea of a non-tampered mail passthru concept. This at 
least should be stated.  For DKIM aware MLM that are resigning, the 
"l=" concern is gone as long as the ODID (Originating Domain Identity) 
accepts the independent MLM DKIM resigning role.

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 19:51:22 -0400

Michael Thomas wrote:
>> Oh heck, let's just declare that the DKIM Signing module MAY output 
>> anything it wants.  
> 
> That's what 4871 did. Manifestly it worked just fine. We had a 
> tremendous number of interoperable implementations. The procrustean 
> insistence that there be a single "output" has not helped 
> interoperability one iota.

Its just really odd that the we need to hide the facts in RFC4871bis 
but not in  RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment 
Guideline)?

Ok, we got it! We need to isolate the signer domain for some future 
market place. I'm saving my pennies for this. Mission Accomplished.

But in the mean time, implementors are not listening. They are looking 
at other things especially the "author thing" we must burn into the 
signature.

Why is it so hard to document these facts in the new revised manual?

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 20:32:54 -0400

Hector Santos wrote:
>>> Hector stated:
>>> I think this message by Barry in March 2009 summarizing a conference
>>> call between Pasi, Stephen and Barry nicely captures the upper/lower
>>> layers, ADSP, i= and outputs conflicts that continue today:
>>>
>>>     http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html
>>>
>> I think that message doesn't say a single thing about layers.  
>> It looks entirely procedural to me.
> 
> Darn it. I copied the wrong link and now I can't find it. :(
> 
> Let me search again...... Quick search failed. I'll search deeper 
> later if you still want me to.  I will find it at some point just to 
> have it in my DKIM notes.

Here is the correct message link:

    Status and direction
    http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html

For all and intent and purposes, this message can be reposted today 
and still bee relevant, covering the final issues we are still dealing 
with.  Note the chairs recommended move forward items, in particular 
#4 which is what I believe we are trying to help with in this WGLC:

   4. *Aim 4871bis at incorporating what we've learned since 4871.*
      If that results in a document that can and should move to
      Draft Standard, we'll do that.  If it does not, then 4871bis
      will go to Proposed Standard, and it will take another
      round of work to move up the standards track.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 01 May 2011 17:52:04 -0700

On 4/30/11 10:37 PM, Murray S. Kucherawy wrote:
> > -----Original Message----- From: Hector Santos
> > [mailto:[email-masked]] Sent: Saturday, April 30, 2011 9:10 PM
> > To: Murray S. Kucherawy Cc: [email-masked] Subject: Re:
> > [ietf-dkim] Output summary - proposing ODID "Originating Domain
> > Identity"
> >
> > But what it did most of for me (yesterday) was highlight the
> > confusion with AUID with the lack of an official DKIM label for an
> > Originating Domain Identity. I guess I was moving forward the past
> > year with integrating DKIM into our mail products and I see now I
> > was mistakenly labeling the AUID as the FROM domain when its not
> > officially defined as the From domain.
>
>  That's unfortunate, but it's also the first case I've heard of
>  someone mistaking the AUID for the From: field.

I think this missed Hector's concern.  Perhaps it would have been 
clearer indicating confusion was in respect to "i=" parameter now called 
the AUID which can be a copy of an address that was within the From 
header field.  The domain can differ whenever the AUID is a subdomain of 
the ODID when allowed by the key rr.

Section 3.5 had stated the following omitted information:

INFORMATIVE DISCUSSION: This document does not require the
value of the "i=" tag to match the identity in any message
header fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 May 2011 18:36:29 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Sunday, May 01, 2011 4:51 PM
> To: Michael Thomas
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"
> 

I've lost track of how many times and how many different ways it's been explained that nothing is being hidden.  I'm going to give up now.

> at other things especially the "author thing" we must burn into the

Which implementers, and why aren't they saying anything?

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 21:40:09 -0400

Is this new text for section 9.1 Misuse of Body Length Limits ("l=" Tag)?

Murray S. Kucherawy wrote:
>
>     INFORMATIVE IMPLEMENTATION NOTE: Using body length
>     {DKIM 2} perhaps based on other criteria.
> 
> I'm fine with the proposed simplification of 9.1, and I 
> think at least Dave and JD have +1'd it already as well.
> 
> Is that acceptable?

+1.

Small note if you are concern about "neophytes."   There are sentences 
where "l=" is referenced where it sounds like the tag is expected to 
be there or needs to used.   So maybe an addition sentence can be 
appended to above:

      Signers do not need to add the "l=" tag to the signature
      if they are signing the entire body.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 May 2011 18:42:33 -0700

> From: Hector Santos [mailto:[email-masked]]
> Sent: Sunday, May 01, 2011 5:33 PM
> To: Murray S. Kucherawy
> Cc: Murray S. Kucherawy; [email-masked]

That message (a) was sent six months before ADSP was published, and (b) was written at a time when ADSP still made use of "i=".  If you take the time to read the text in RFC5617, it doesn't use "i=" at all.

> and still bee relevant,

...except that it doesn't cover what the working group actually published.

> covering the final issues we are still dealing

Sounds like precisely what we've done.

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 22:13:36 -0400

> I've lost track of how many times and how many different ways 
> it's been explained that nothing is being hidden.  I'm going to 
> give up now.

If nothing is being hidden, then why not explicitly add AUID and ODID 
(or RFC5585.From.Domain) to the Output Summary?  Whats the danger?

Maybe its not a "Output Summary?"

Here are some definitions for a summary [1]:

    A summary, synopsis, or recap is a shorter version of the original.
    Such a simplification highlights the major points from the much
    longer subject, such as a text, speech, film, or event. The purpose
    is to help the audience get the gist in a short period of time.

    An abstract or a condensed presentation of the substance of a body
    of material; concise, brief or presented in a condensed form;
    Performed speedily and without formal ceremony

etc.  What you are proposing is just the redundant "Mandatory Output" 
information, and not a "DKIM Output Complete" summary that reflects 
current implementations.

> Which implementers, and why aren't they saying anything?

Well you, I did and many in the archives has say things, and many have 
stated very clearly the ODID is considered a very fundamental part of 
DKIM.  RFC5585 reflects how signing practices is part of the expected 
DKIM Architecture.

The two open source APIs:

    OpenDKIM
    ALT-N

has support for signing practices.

Systems using A-R to report DKIM results are using AUID, such as 
Dave's MLM.

And I know our DKIM product has direct support for the design 
described in RFC5595 including A-R with all four outputs (status, 
SDID, AUID, ODID) as well as the ADSP extensions.

The biggest software company, Microsoft, has announced ADSP support 
and that means ODID output is required.  How can that be not significant?

Yes, it is getting tiresome because it is real hard to understand why 
adding the obvious to the Output Summary is a problem. What harm is 
there?  None that I can see.

Why isn't there any mediated compromise to settle these 5-6 years 
conflict?

In my view, your proposed section 1.1 DKIM Architecture Documents and 
with adding the AUID and ODID as part of the output to make all the 
documents protocol consistent will settle the issue, in my view, for 
all parties.

[1] http://www.google.com/search?rlz=1C1CHMG_enUS291US310&q=define:summary

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 22:25:25 -0400

Murray S. Kucherawy wrote:
> That message (a) was sent six months before ADSP was published, 
> and (b) was written at a time when ADSP still made use of "i=".  
> If you take the time to read the text in RFC5617, it doesn't use 
> "i=" at all.

Since day one POLICY anchored off the ODID in the same way Domainkeys, 
which has inherent support for POLICY, anchored off the ODID.

There were suggestions as Barry noted due to the ambiguity (which 
remains today) for what i= should be and that included i=From and thus 
possibly it could be the feed for policy.   But we also talking the 
ideas of extension modeling and outputs to pass to them. It was the 
beginning of reducing it to one only - signer and only for trust 
purposes, excluding the needs for ADSP.

>> For all intent and purposes, this message can be reposted today
>> and still bee relevant,
> 
> ....except that it doesn't cover what the working 
>     group actually published.

Exactly, which is why we still have the issues today.

> Sounds like precisely what we've done.

I take the position that 4871bis does not incorporate what we have learned
since 4871.  If it did, these concerns would not be on-going.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 May 2011 20:46:19 -0700

On 5/1/2011 6:36 PM, Murray S. Kucherawy wrote:
> I've lost track of how many times and how many different ways it's been
> explained that nothing is being hidden.  I'm going to give up now.

+1

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 May 2011 00:24:27 -0400

Dave CROCKER wrote:
>> explained that nothing is being hidden. 
> 
> 
> +1

Good.  So there should not be a problem *not* hiding an explicit 
identity definition required to complete the DKIM Service Architecture 
in RFC5585:

       INFORMATIVE IMPLEMENTATION NOTE:

       The ODID and SDID are inputs for the optional
       Checking Signing Practices component as described
       in the DKIM Service Architecture [RFC5585]

If something like this is not added or anything close to it, I don't 
know any other way it can be described but an intentional neglect to 
mention anything closely related to it.

I would like to ask the chairs if we can get Consensus Reevaluated. 
 From the limited WG participants providing input, it appears we have 
Rough Consensus for this identity to be included in RFC4871bis.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 02 May 2011 09:53:25 +0200

> The message should be don't use l= if you care about your signature.

I mostly agree on that.  However, the way it is stated in version -09, it may
be overlooked.  IME, your message [1] prompted me to conceive an actual
example, which in turn makes me want to amend my signer's configuration.
Thus, I believe the current text requires some extra diligence to have the
desired effect.

[1] http://mipassoc.org/pipermail/ietf-dkim/2011q2/016002.html

> that the problems it causes are far greater than whatever problems it 

As Hector notes, it is required by non-DKIM aware MLMs.  The point is that
relaying MTAs seldom know whether the target is a MLM, let alone whether
DKIM-aware.

Perhaps reasoning should go like this:  Let's assume we can sign according to
the target, then what would we do with a non-aware MLM?  If the answer is to
avoid signing in such cases, then omitting l= and letting the signature break
is just equivalent --except for aesthetic considerations...

Please consider the environment before printing the header of this e-mail
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 02 May 2011 12:27:44 +0100

+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: "John R. Levine" <[email-masked]>
Date: 2 May 2011 10:21:07 -0400

> As Hector notes, it is required by non-DKIM aware MLMs.

To aim one more kick at the greasy spot on the floor where the horse used 
to be, MLMs break signatures in a hundred ways, l= lets you work around 
one of those hundred ways at the cost of making your signature worthless.

> is just equivalent --except for aesthetic considerations...

Since a proper DKIM implementation ignores broken signatures, you sign 
everything.

Can we stop arguing about this now?  These points were all hashed to the 
point of exhaustion a year ago.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 02 May 2011 16:51:36 +0200

>           "Consensus needs to be reevaluated"

IMHO, it needs not:  It is premature to define an ODID now.  ADSP is
considered somewhat broken, and for this message, for example, it seems that
the relevant id should be "mipassoc.org" rather than "tana.it".  ODID would
risk to be a candidate for removal like AUID.

>From an engineering POV, policy developments are closely related to the
verification software, as a matter of facts, so that cleaning up the
definition of the interface between them doesn't seem to be urgent.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 2 May 2011 15:34:27 +0000

On Thu, Apr 28, 2011 at 7:00 PM, Rolf E. Sonneveld
<[email-masked]> wrote:

<snip>

>  From the design view of DKIM I know we should not want it, but what if
> we would add the From address as a third _required_ output parameter?
> With From: I mean: that particular From address that was used to verify
> that particular signature for which the success status is handed over.
> So if there are two From's, and only one signature verifies, the upper
> layer application knows for which of the two From addresses the success
> status applies. Then the upper layer applications are enabled to perform
> whatever they want to do. Wouldn't that also mitigate the problem of
> multiple singletons present?
>
> As the From: address is mandatory input for the signature, it may be a
> logical step to also make it mandatory in the output?

If we simply view DKIM as one module of many that are used to make a
decision, then the decision process can choose which modules are
needed to make a choice. For example, one could use the DKIM module
and RFC5322 header module, while another could use the DKIM module,
the RFC5322 module and the ADSP module.

So, while it may be convient for DKIM to provide RFC5322From, it is
obtainable via other ways. I think DKIM's output should just be the
DKIM bits.

-- 
Jeff Macdonald
Ayer, MA

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 2 May 2011 16:01:21 +0000

>>       in the DKIM Service Architecture [RFC5585]

-1

-- 
Jeff Macdonald
Ayer, MA

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 May 2011 12:31:03 -0400

> risk to be a candidate for removal like AUID.

IMV, ADSP is only broken in that it didn't allow you to declare you 
were allowing mipassoc.org to sign for you or in general

       "My Mail Is Always Signed - by me or someone else."

The only point here is that you did declare an ADSP record 
(DKIM=UKNOWN) and to get that record, the verifier needs an ODID to be 
an identity to satisfy the DKIM Service Architecture as described in 
RFC5585.   All the arguable semantics of its value is not the point in 
the same way regarding the value of SDID.

     Side Note: Relaxed ADSP policies is a high overhead redundant waste
     on receivers because the results are indeterminate.  This is the
     same reason why SPF relaxed policies are wasteful too and more
     domains are changing to a HARD FAIL (-ALL).

> definition of the interface between them doesn't seem to be urgent.

Well, sure, current implementations are already supporting AUID and 
ODID and RFC4871bis doesn't reflect that.

Just look at the A-R header recorded by mipassoc.org for your 
submission signature (that was stripped):

   Authentication-Results: sbh17.songbird.com;
      dkim=pass (1024-bit key) header.i=@tana.it

It reported AUID, not the SDID.

What makes it all harder is DKIM Mail Integration.  We are using the 
A-R to help with adding DKIM related attribute information to import 
mail into our backend mail storage.  We know what to do because of the 
5-6 years of being involved with DKIM. But if a new engineer is 
looking at RFC4871bis, they are not going to gain from all the current 
implementations experiences.  They will need to read RFC5585 (DKIM 
Service Architecture) and maybe even RFC5863 (Deployment) and probably 
at some point ask themselves or their boss ask them about security 
issues and get that from RFC4686 and what will they see?  Something 
about POLICY called ADSP and then ask, ok, what output from RFC4871bis 
is needed to support this thing called ADSP.  They will find "hmmm, 
there is nothing about it in RFC4871bis. Ok, its the domain in 
RFC5322.From."

All I am saying, lets add that semantic into RFC4871bis and make life 
easier for the next guy.  I guess he will eventually find out at some 
point and maybe that is what you mean that it isn't urgent.  Ok, sure. 
  But we have been so anal with so many other little things, word 
changes, worried about him not using l= tag or whatever, that we 
missed out on bigger things he will probably need.

Anyway, my opinion.

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 May 2011 13:39:26 -0400

>        "My Mail Is Always Signed - by me or someone else."

By the way Alessandro, you could explore ADSP/ATPS support from your 
record. Use this wizard:

       http://www.winserver.com/public/wcadsp

When you set the author domain; tana.it, unclick ASL, click ATPS, and 
add authorized signer; mipassoc.org and also add mipasoc.org for the 
test field, click test, you will see:

;
; ATPS (v01) Zone Records for author-domain: tana.it
; Generated by wcMakeADSP v2.3(c) copyright 2010 Santronics Software,Inc.
;

_adsp._domainkey  TXT ("dkim=all; atps=y;")

N3LSEHML2WGBFXOV7HSAK2QZSUBSEFHB._atps  TXT ("v=atps01; d=mipassoc.org;")

with a test result:

  Authentication-Results: verifier-machine.tana.it;
     adsp=pass policy=all author.d=tana.it signer.d=mipassoc.org (atps 
signer);

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 2 May 2011 12:31:22 -0700

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 02 May 2011 22:14:03 +0200

On 5/1/11 6:55 AM, Dave CROCKER wrote:

[...]

> therefore it is entirely inappropriate -- that is, out of scope -- for the
> specification to suggest dealing with it.

You mean 5322.From?
And how should we read par. 3.2.2 of RFC4686 if it is out of scope for 
DKIM to deal with it?

    Bad acts related to email-based fraud often, but not always, involve
    the transmission of messages using specific origin addresses of other
    entities as part of the fraud scheme.  The use of a specific address
    of origin sometimes contributes to the success of the fraud by
    helping convince the recipient that the message was actually sent by
    the alleged author.

    To the extent that the success of the fraud depends on or is enhanced
    by the use of a specific origin address, the bad actor may have
    significant financial motivation and resources to circumvent any
    measures taken to protect specific addresses from unauthorized use.

    When signatures are verified by or for the recipient, DKIM _is
    effective in defending against the fraudulent use of origin addresses_
    on signed messages.

Although 5322.From is not mentioned here, how can DKIM provide any level 
of defense against fraudulent use of origin addresses, if d= is the one 
and only mandatory output of the verification process?

Or should we declare this paragraph obsolete?

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 May 2011 13:22:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Monday, May 02, 2011 1:14 PM
> To: [email-masked]
> Cc: [email-masked]

Yes, I think that's what he meant.

> and only mandatory output of the verification process?

Why does the output of DKIM need to include something when the consumer of that output already has that information?

> Or should we declare this paragraph obsolete?

It could stand some revision, I suspect.

Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value.  It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries.  But DKIM is a key component to that overall system.

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 May 2011 19:58:23 -0400

Murray S. Kucherawy wrote:

> Why does the output of DKIM need to include something when the 
> consumer of that output already has that information?

Its not really how data is obtained but what Data is needed for

     ADSP
     TRUST

as described as part of the RFC5585 design.

One can reasonably state that the true definition for Output is all 
INPUT that went into the signature and the result code:

    HLIST     (All the signed headers, h=)
    SDID      (d=)
    SELECTOR  (s=)
    AUID      (i=, if defined)
    HASH      (strength)
    RCODE     (Verifier result code)

Its understood the new 3.9 is burning in what is only value required 
and its for a presumingly a required trust assessor since "d=" value 
MUST be passed to it.

So why not add a reference to VBR?  You have a MUST there to pass to 
something, help promote VBR to fulfill the MUST.

All is that is being asked is cross the tees, dot the eyes for RFC5585 
with a MAY for ODID.  You don't even have to mention ADSP, just say 
its an optional part of the total DKIM Service Architecture.  Just 
like VBR is, just like A-R is.

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 May 2011 21:01:22 -0400

Murray S. Kucherawy wrote:

> Nevertheless, the overall threat model doesn't require that 
> DKIM itself, i.e. the protocol being defined, also be the 
> thing that evaluates origin addresses for validity or value.  
> It's certainly legitimate to leave that to other modules, just 
> like SMTP isn't required to do any evaluation work of the 
> payload it carries.  But DKIM is a key component to that 
> overall system.

Ahhhh, and the SMTP difference is it did not exclude it in either for 
any SMTP level values and/or payload:

For the client domain, it is a REQUIRE to be valid but not a reason 
for rejection (due to historical hiccups):

For the return path, it is REQUIRE to be valid yet it left the door 
open. See RFC5321, section 3.3:

    3.3 Mail Transactions

    .....

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the reverse-path may
    not be determined until one or more forward-paths (in RCPT
    commands) can be examined.  In those cases, the server MAY
    reasonably accept the reverse-path (with a 250 reply) and then
    report problems after the forward-paths are received and
    examined.  Normally, failures produce 550 or 553 replies.

For the forwarding path, if you are an open relay or if you have an 
old computer(s) and can't scale up or out, you just accept it. But 
more modern systems do local recipient validation checks or just for 
policy reason

    "450 Sorry, user [email-masked], didn't pay his pennies this month!"

For the Data Payload, the fact you can do a 45x/55x is an explicit 
specification that for want ever reason you have, it can be 
temporarily or permanently rejected. RFC2821 learned since RFC821 with 
an explicit insight for delays in DATA EOD responses in section 6.1 
last paragraph

    To avoid receiving duplicate messages as the result of timeouts, a
    receiver-SMTP MUST seek to minimize the time required to respond to
    the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [40] for
    a discussion of this problem.

This is all recognizing the market place increasingly doing payload 
evaluations to address the highly exploited Accept/Bounce "Responsible 
System" requirement.

The problem with RFC4871bis is that its locking in a specific assessor 
with only one mandatory feed.   It fails to say:

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the signature may
    not be determined until ODID (RFC5322.From.Domain value)
    can be examined.  In those cases, the verifier MAY
    reasonably accept the signature (with a ADSP=PASS status) and
    then pass the SDID to the Trust Assessor Module.

See the difference between the BIS for SMTP vs the BIS for DKIM?  2821 
incorporated what was learned other documents since 821.  Its hard to 
extract 4871bis has learned from any of the current experiences 
document nor ready for 2011+ operations accept only for trust.

2821 nor 5321 does not say anything about any one process output being 
mandatory as a MUST for a specific any evaluation. But it was all 
allowed via reply codes just giving way for state machine hooks, shims 
and extensions and augmented technology - SPF for MAIL FROM and DKIM 
for the DATA payload.

---

From: Hector Santos <[email-masked]>
Date: Tue, 03 May 2011 10:22:35 -0400

Rolf E. Sonneveld wrote:
>> the
> ....

I think Dave can make it more easier for policy advocates to better 
understand his statement:

by explaining it terms of Protocol Consistency using what is already 
defined in the "Requirements for a DKIM Signing Practices Protocol" 
(RFC5017) section 5.3, item #10:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

In short, if there is a Trust Assessment logic at the Verifier and it 
sees a valid signature signed by a trusted domain, then 1st party 
policies MUST NOT (according to item #1) apply.

No one disputed this.  The problems was:

   1) Allowing 1st parties to declare it allows 3rd parties to take over,
   2) Dealing with anonymous fraudulent abuse streams,

Until there is universal trust assessment coverage in greater numbers, 
verifiers will be dealing with a lot of uncertified or unknown signers.

Nonetheless, none of this should exclude the idea of an ODID identity. 
Its there, it exist, its in the mandatory RFC5311.From and we should 
allow Local Policies continue to dictate how it will evaluate the 
blasting of DKIM signed mail on this system.  Until SDID can be useful 
with a payoff, verifiers will need a fall back with ODID.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 04 May 2011 00:55:30 +0200

On 5/2/11 10:22 PM, Murray S. Kucherawy wrote:
>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
>> To:[email-masked]
>> Cc:[email-masked]

Because a consumer should/must not have to re-do the work of the DKIM 
verifier. Or put it differently: a consumer is just consuming the output 
of the DKIM verification process, it will rely on it (provided there's a 
trust relation between consumer and verifier), and it normally will not 
re-do the work of the DKIM verifier. It has no knowledge of DKIM rules 
(bottom up etc.). Just like a MUA has no information about how two MTA's 
exchange a mail over SMTP.

So for the consumer it is essential to get, in addition to the d= and 
the status, the From address that was used to construct the signature. 
That way the consumer can act upon this triplet of information.

> Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value.

Agreed.

> It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries.

Agreed.

> But DKIM is a key component to that overall system.

Because DKIM is a key component to the overall system, it must provide 
reliable information about the origin address to those 'other modules'. 
If DKIM is not designed to provide that, we'll have to declare par. 
3.2.2 of RFC4686 to be 'status: historical'.

Question: does DKIM say anything about the 5322.From header value? If we 
agree with Dave, we'll have to admit that DKIM does not address the 
threat described in par. 3.2.2 of 4686, do you agree?

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 May 2011 16:25:29 -0700

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 3:56 PM
> To: Murray S. Kucherawy
> Cc: IETF DKIM WG

The assertion you're making is that the consumer of an API shouldn't need to maintain any context; the API will give you back all the bits of context you need to continue as well as the answer you need.

If you feed N bytes of data to a hash function, what you get back is the resulting hash, not the hash and the source data or maybe the hash and N.  All of the context is still in the API consumer, not in the function that's giving you what you want.

If you give RSA_Verify() a signature, a public key and a hash, it gives you back a 1 if they match and a 0 otherwise, not 1/0 and then some of that same information you gave it.  The caller is the part of the system that knows what the answer is telling you, because it understands the nature of the function it called.

So it is with DKIM: If you get back an indication from a verifier function that a signature verified, then the signature covered the lowest From: field that you presented to it.  You know that because that's how the interface you're using was defined.

An implementation certainly could give you back that From: field's contents (and OpenDKIM does, if you ask for it), but still I don't see any reason to make it mandatory.

I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated, even if it was signed, is quite possibly asking for trouble.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 03 May 2011 23:58:18 -0700

> An implementation certainly could give you back that From: field's contents (and OpenDKIM does, if you ask for it), but still I don't see any reason to make it mandatory.
In the process of finding the bottom of the header stack, DKIM will have 
read all headers.  DKIM must also count headers as it advances up the 
stack.  Senders signing with DKIM likely do so to better protect 
recipients and to obtain higher use rates.  While conventions regarding 
header limits may change, headers limited to one are unlikely to have 
these limits change due to security issues.  It is also likely those 
using DKIM conform with current stricter requirements and can signify 
this simply by listing them in the signature header field.  Refusing to 
validate malformed email is important to prevent DKIM results from being 
misleading.  Counting header fields is trivial compared to public key 
cryptography.  Not noticing deceptive pre-pended header fields may mean 
DKIM could cause more harm than good.   Nothing in in DKIM's API needs 
to change for DKIM to provide the desired protections being sought.

-Doug

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 04 May 2011 00:57:09 -0700

> I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated,…
This is a remarkable statement.  DKIM's verification of the signing 
domain provides a basis upon which contents of the message may be 
trusted.  That trust most certainly includes the important From header 
field.  In fact, only the From header field MUST be included in the DKIM 
signature.  As such, clearly defining what constitutes the From header 
field IS important.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 04 May 2011 10:23:50 +0200

> So it is with DKIM: If you get back an indication from a verifier function that a signature verified, then the signature covered the lowest From: field that you presented to it.  You know that beca…

For a scenario where a caller is calling a DKIM milter which in turn 
calls an API, this is all true. But DKIM will be/is deployed in many 
more scenario's. Consider scenario's like:

    * there can be one or more hops between verifier and consumer
    * between verifier and consumer MTA's can re-order From headers,
    * or remove From headers if there is more than one of them present.
    * What if Postini and MessageLabs are going to use DKIM for inbound
      traffic for their customers and want to communicate the DKIM
      verification results to the consumers within the mail infra of
      their customers?

> I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated,…

But then DKIM is only authenticating the d= and we should no longer 
position DKIM as being 'effective in defending against the fraudulent 
use of origin addresses'.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 05:27:45 -0400

Rolf E. Sonneveld wrote:
>> The assertion you're making is that the consumer of an API shouldn't 
>> need to maintain any context; the API will give you back all the bits 
>> of context you need to continue as well as the answer you need.
>>
>> ..
>>
>> So it is with DKIM: If you get back an indication from a verifier 
>> function that a signature verified, then the signature covered the 
>> lowest From: field that you presented to it.  You know that because 
>> that's how the interface you're using was defined.
> 
>> An implementation certainly could give you back that From: field's 
>> contents (and OpenDKIM does, if you ask for it), but still I don't see 
>> any reason to make it mandatory.
>>
>> I might even go so far as to say returning that From: field is 
>> dangerous since it is not confirmed by anything, so DKIM (which is an 
>> authentication protocol) returning data that can't be validated, even 
>> if it was signed, is quite possibly asking for trouble.
> 

+1 well said.

Let me show examples of the DKIM mail integration dilemmas. My apology 
for the length of this, but I am trying to extract all the key design 
issues we are facing or will be facing with DKIM:

A fundamental flaw is to believe all backends have a RFC5322 Mail 
Store. The protocol has to provide for discovery for the software 
engineering interface points to engineer the integration and 
transformations needs.

RFC4871bis is saying there is an mandatory interfacing point for a 
trust transformation and believing that leaving the door open with 
stating the possibility of other outputs is universally obvious.

For a DKIM software engineering minimal, DKIM-BASE needs to expose the 
interface points such the ODID (or From) and the AUID which is 
explicitly stated as a MAY therefore it should also be part of the 
Outputs.  Reasonable engineers to exptract from RFC5585, RFC4686 the 
interface points for  the "black box" transformed outputs.

There are only four minimal elements that can be extracted based on 
all the different considerations since RFC4871 with all the related 
consensus built documents:

        verification status
        SDID   signer domain
        AUID   agent/user identity
        ODID   author domain

Everyone will need those parameters to satisfy the DKIM Service 
Architecture which includes security, policy and trust considerations.

When one actually begins to employ DKIM in a total mail systems that 
includes:

    - internet hosting with SMTP, POP3, NNTP, MLM, IMAP, etc,
    - how mail is stored and/or transformed, and
    - online/offline MUA considerations

it become more clear of what inputs/utputs are needed for DKIM 
purposes and also the complexity of where the "trust" increases and 
decreases.

Example:

Remote UserA sends dkim signed mail to Local UserB and Local UserC at 
the same local mail host.

UserB likes to use the Online Mail Access (Web site, but it can be any 
other online connection device).  UserC was an online person, but he 
slowly migrated over the years to an offline RFC-based Mail 
Reader/Writer (Outlook, Eudora, Thunderbird and many others).

UserB - online user.

It should be fairly obvious that the centralized backend has rendering 
control for UserB and has all the power to provide the security, 
policy and overall trust outcomes the UserB.  During the import 
process from remote userA, depending on the backend storage method, 
the information was generated necessary for the backend to display the 
information to the UserB.   To assume the backend will do the 
verification dynamically with each message reader, while possible, 
probably not very efficient.  So the odds are good the verification 
was be done once and all the outputs will need to be stored.  Whether 
one is using a raw RFC54322 storage method or it is protocol assumed 
that is expected is not the point because in cases, the output must be 
common.  What is important to consider is that it is backend that is 
telling UserB and all online access users is that what they see 
"should be" trusted (at least in the header display)

UserC - Online User.

Let uses POP3.  Backends don't have control of what is display or how 
it will be displayed at the header level.  We have historical BCP 
across all mail systems and in all mail networks, that at the very 
least it will have, in no particular order:

   Date:
   From:
   To:
   Subject:

Since there is a time-shifted mail application, you might also see a 
received or reception date because its not generally the same as the 
originating date.

What it is important though that it is RFC5322 based and whatever DKIM 
related  information the backend wishes to provide to the UserC will 
be included in the headers. This is important as I described in the 
second part of this UserC offline mail consideration.

What is also important is an "inherent" trust factor for the UserC 
using the backend mail host. Its not an blind consideration for the 
user to pick or use a particular mail host. So even if it was not 
possible for the backend to display that security, policy, trust 
information that was certifiably verified once already at the backend 
to the user, UserC does have some, possibly faulty, level of trust 
already.

So the question of whether the offline MUA duplicating this 
recalculation become more relevant - for UserC sake.

What I think about what can be displayed to the DKIM-aware or perhaps 
just a simpler DKIM-Report-Aware MUA so that he doesn't have to redo 
the calculation DKIM overhead in a trusted manner.

Can an Authentication-Results header from the same Backend Mail Host 
only (1 degree of separation) be used for the DKIM-Report-Aware MUA?

Remember, the offline MUA may independently decide not take user 
considerations into account for a trusted backend and just do what it 
thinks is best or a more advanced DKIM ready MUA may provide the DKIM 
related user options along with the other common MUA mail pick up 
options already existing for an account setup:

    [_] Enable DKIM support
        (o) Use A-R DKIM results from the same mail host
        (_) Calculate the DKIM verification.

So things are possible.

There is also other methods a backend can do and this is based on 25+ 
years of offline product design experience.  Overall the product goal was:

     Providing the same (or equal) reading experiences and
     security requirements necessary for online access in
     a time-shifted offline manner.

For those who were in this market, it is fairly obvious.  But this 
highlights two things:

     - Backend transformation (i.e. POP3 transformation to RFC5322)
     - New ideas to support legacy MUA using forced display header changes

You have to accept the idea for the long history of many backends with 
real motivations to transform RFC5322 into proprietary backend store 
formats (i.e. one may be to limit/lower PCI related security concerns 
regarding HTML/Javascript exploits, another are mail streams where 
multi-media is not important, there are many reasons including 
reducing storage space requirements).  But for the user who has 
migrated to offline access, the idea of giving them original content 
perfection became more relevant and a tougher local policy decision.

But still have growing needs to address the market of legacy or better 
the BCP MUA design where essentially there is no standard protocol to 
control what headers are displayed.   There are two ways to approach this:

1) Wait for the Offline MUA to die off

We have a new recycling towards centralization, and we can just wait 
out the departing generation of Offline MUA users and focus designs 
towards Online MUA access.   You can see this in high-value email 
notifications with secured content design that is based on the idea is 
reading it online.  You can also see this with the recent Microsoft 
move to remove and no longer supporting the 20+ years of 
microsoft.public.* newsgroups and shifting it to online mail forums.

2) Proxies

You can design proxies or design backend forced changes in the header 
display to reveal more information.  For microsoft, their migration 
solution included a backend API Proxy for NNTP client/servers to 
assist the market of RFC-based News Readers.  Since their proxy was 
limited, had Input/Output transformation bugs, others wrote better 
proxies. I wrote one as well called "Wildca! Live Exchange" 
(http://opensite.winserver.com/wclex).

The goal again was to give the Microsoft Online Reading experience 
which now included all the new outputs to display, in an offline 
manner. Using a few of the  output examples, online you see stuff like.

    From: Whoever
    Status: MVP
    Stars: 1 to 5
    Member Since:
    Number of Posts:

Those are all "Trust" ideas in the area of what users can believe or 
accept or not in solutions value.

So with WcLEX,  some of the outputs where used in setting the 
RFC5322.From, so the news reader using the wcLEX proxy:

    From: Whoever [MVP, Stars: 4, Post: 243] <whoever@msforums>

and wcLEX also haves options to write this and more backend details in 
the content using mixed html/text MIME parts.

In summary, if RFC4871bis focuses on just exposing what is a single 
mandatory output and not what is DKIM Output Complete, certainly life 
doesn't end, but it does certainly makes it harder to extract and 
derive necessary mail integration solutions.

DKIM-BASE certainly makes it clear what is mandatory and if we just 
focus on that and totally forget about ADSP and other things related 
to it, then its easy to see what is only needed to convert to UserB 
and UserC.

      Signing by:
      Trusted Signing by:

and the problem is that the default design is to lock that in. 
DKIM-BASE should allow for all the minimal extracts that can be obtained:

      Signing by:
      Trusted signing by:
      Authorized signing by:
      Authorized and Trusted signing by:

I am not saying that just because I am strong advocate for policy, but 
it is all part of the total mail integration picture based on what 
what encompasses the current DKIM mindset and considerations.

Future implementators will be at an disadvantage and fortunately, we 
were able to get the new section 1.1 which the additional "clues" for 
engineers to find out all that is needed.  But it would be so much 
simpler if the new Output Requirements section was a better summary of 
the DKIM Output Complete values to consider.

I know one thing, DKIM is a complex beast and the last thing we need 
is more protocol relaxation and incomplete exposure of information in 
indirect and ambiguous ways we know offer utility.

---

From: "John R. Levine" <[email-masked]>
Date: 4 May 2011 08:04:00 -0400

> For a scenario where a caller is calling a DKIM milter which in turn calls an 
> API, this is all true. But DKIM will be/is deployed in many more scenarios.

Indeed, but you're misunderstanding the point of a standard.  The DKIM 
spec tells signers how to create a signature that recipients can verify, 
and it tells verifiers how to check whether a signature is valid.  The 
spec is not an implementation guide for every possible implementation 
scenario.

We're allowed to assume that the spec will be implemented by reasonably 
competent programmers.  I think reasonably competent includes figuring how 
to maintain or communicate the external state needed to do what you want 
to do.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 06:29:17 -0700

On 5/4/2011 1:23 AM, Rolf E. Sonneveld wrote:
> But then DKIM is only authenticating the d= and we should no longer position
> DKIM as being 'effective in defending against the fraudulent use of origin
> addresses'.

Besides your rather unusual sense of software architecture, your above statement 
seems to indicate a failure to attend to differences between rfc4871 and rfc4871bis.

Which documentation makes your above claims?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 06:41:44 -0700

> spec is not an implementation guide for every possible implementation
Indeed, this is precisely why it's silly to say there is a single
"output" of the protocol. Take IKE and KINK, for example: the
"output" is a complex set of parameters that eventually lead
to the keying of a SA given the identity in the cert/ticket. They
are *all* relevant and not just "internals". Similarly, DKIM
signatures have a lot of relevant information for filters to do
the magic that filters do, and they by their nature find utility
in information that is being walled off by -bis as being "internal".

And please stop trying to have it both ways: it's either "internal"
or it isn't. Developers have a funny way of taking these documents
literally and when you say it's "internal", they make them internal
in fact. We need to pick a lane, and "single output" clearly does
not match the real needs of all DKIM consumers.

4871 had it right on this account. Everything since then has
screwed the pooch. Put it back.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 09:48:31 -0400

John R. Levine wrote:
>> For a scenario where a caller is calling a DKIM milter which 
>> in turn calls an  API, this is all true. But DKIM will be/is 
>> deployed in many more scenarios.
> 
> competent programmers.  I think reasonably competent includes 
> figuring how to maintain or communicate the external state needed 
> to do what you want to do.

Beside the point that there are conflicts, these are all valid points 
and the issue is beyond validity or rather how DKIM-BASE goes beyond 
the validity question.

The mandatory single output for SDID attempts to mandate a specific 
receiver design implementation where the message is valid and trusted 
if they have the local or query method available for evaluating trust 
for SDID.  It is a MUST design by DKIM-BASE standards and this SDID 
trust policy design mandate is not the issue for the receiver.  We get it.

The issue is that receivers also have serious security controls, 
anti-abuse operational needs.  With the #1 market of signers being 
spammers increasing using DKIM in some silly idea that it will give 
them brownie points,  DKIM redundant abuse will not be tolerated and 
it doesn't help DKIM to live in indeterministic world where SDID is 
unknown or provides no trust results.

Reasonable competent manager, software engineers and programmers will 
look at the pretty picture called "DKIM Service Architectures" - we 
all like pictures - and determine very quickly what is the inputs and 
outputs.  It shows in graphically process flow iconic form what is 
required and what is optional.

The design issue is that not all outputs are not spelled out in the 
Functional Specification for DKIM. It doesn't match what RFC5595 calls 
the "DKIM Service Architecture."  RFC4871bis does not reflect what 
receivers need for security controls.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 04 May 2011 16:04:29 +0200

On 5/4/11 3:29 PM, Dave CROCKER wrote:
>> position
> Besides your rather unusual sense of software architecture, 

This comment is not very constructive, especially as it lacks any 
information about /what/ it is, that is unusual.

> your above statement seems to indicate a failure to attend to 
> differences between rfc4871 and rfc4871bis.
>

Both documents refer to rfc4686, albeit only in the Informative 
References section. rfc4871 refers to rfc4686 only in section 8, 
rfc4871bis in section 8 as well as in section 1.1.

Please provide us some pointers regarding the differences between 
rfc4871 and rfc4871bis in relation to the above statement.

/rolf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 07:08:43 -0700

On 5/4/2011 7:04 AM, Rolf E. Sonneveld wrote:
> Both documents refer to rfc4686, albeit only in the Informative References
> section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as
> well as in section 1.1.
>
> Please provide us some pointers regarding the differences between rfc4871 and
> rfc4871bis in relation to the above statement.

The claim that rfc4871bis has the goal you claim is yours.

So you need to do the work of subtantiating it.

So far, as you acknowledge, your only reference is quite old, merely 
informative, and not a specification.  In contrast, rfc4871bis declares the goal 
of its specification and it's not the one you assert.

You've now had multiple people responding to this thread with various 
explanations why it is off the mark.

We should be done.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 07:58:33 -0700

> explanations why it is off the mark.

This is a good example of why this effort has come off the rails.
Going from 4871 to DS should have been a fairly straightforward
effort considering the high degree of interoperability we achieved.
Instead of just removing a few unused features, we've seen a
wholesale rewrite when one was manifestly not needed. Worse,
is that when that history is mentioned it is either disregarded
or sneered at by the senior editor. That is a problem.

This entire process needs a reset, starting with the choice of
editors. We are so far afield of what RFC 4871 was that it's impossible
to understand the implications of the subtle changes that have been
introduced. RFC 4871 worked. It did not need anywhere close to this
level of "fixing".

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 11:13:27 -0400

Douglas Otis wrote:
>> dangerous since it is not confirmed by anything, so DKIM (which 
>> is an authentication protocol) returning data that can't be 
>> validated, even if it was signed, is quite possibly asking for trouble.

+1

Maybe Murray's point was depending on the software, up, down, sideways 
reading, it would be possible for the wrong ODID would be extracted.

But before that can happen, the signature would be invalid (Invalid 
RFC5322, Multi-From found).

Therefore, only one ODID header will be outputted.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 08:16:50 -0700

Michael,

> or sneered at by the senior editor. That is a problem.

"Wholesale rewrite"?  Well, that should be easy for you to document, given how 
convenient it is to point to the existing diffs.  The task when citing a problem 
with changes is to point to /specific/ changes that are problematic.  That 
requires some work.

In particular, please cite normative differences.

As for the particular difference between rfc4871's statement of DKIM's purpose 
and rfc4871bis' statement, you might want to review the language in the Service 
Overview and the Deployment documents.  On this issue, the working group's 
learning process has been incremental and well documented.

As for 'sneering' at history, please do cite that occurrence, too.  Please 
distinguish between citing history versus sneering at it.  Explaining the 
criteria that qualifies as 'sneering' would be helpful.

I am also surprised to discover that we have any junior editors or, for that 
matter, that editors are distinguished by seniority.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 08:18:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, May 04, 2011 7:59 AM
> To: [email-masked]
> wholesale rewrite when one was manifestly not needed.

Has anyone other than me bothered to generate and review the complete diff?

This is a gross exaggeration of what's actually changed.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 08:41:00 -0700

On 05/04/2011 08:16 AM, Dave CROCKER wrote:
> "Wholesale rewrite"?  Well, that should be easy for you to document, 
> given how convenient it is to point to the existing diffs.  The task 
> when citing a problem with changes is to point to /specific/ changes 
> that are problematic.  That requires some work.
>

As I've already mentioned: the notion of "output" is a huge NORMATIVE
change. It should have never been allowed as a piece of errata, and
continues to cause all manner of issues. 4871 was NOT BROKEN in this
respect. We have no business telling developers what the layering
relationship is between the DKIM verifier and its consumers.

> As for the particular difference between rfc4871's statement of DKIM's 
> purpose and rfc4871bis' statement, you might want to review the 
> language in the Service Overview and the Deployment documents.  On 
> this issue, the working group's learning process has been incremental 
> and well documented.

Asleep at the switch is a more accurate portrayal. By the time any of this
effort started, we had a wealth of interoperability information which 
resulted
in the non-controversial parts of the errata, and stable unchanging
implementations. The "learning" should be to leave well enough alone,
instead of changing things just for aesthetics and quite likely breaking
things in the process, either purposefully or inadvertently.

>
> As for 'sneering' at history, please do cite that occurrence, too.  
> Please distinguish between citing history versus sneering at it.  
> Explaining the criteria that qualifies as 'sneering' would be helpful.

You need look only at the piece that I quoted from. Your continuous use of
ad hominem attacks is well documented.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 10:44:59 -0400

Dave CROCKER wrote:
>> References section. rfc4871 refers to rfc4686 only in section 
>> 8, rfc4871bis in section 8 as  well as in section 1.1.
>>
>> Please provide us some pointers regarding the differences 
>> between rfc4871 and rfc4871bis in relation to the above statement.
>

It showed that.  Are you suggesting security is not part of DKIM's goal?

> So you need to do the work of subtantiating it.

The proof of concept was done in the WG consensus built RFC4686 security
document.

> informative, and not a specification.  In contrast, rfc4871bis declares 
> the goal of its specification and it's not the one you assert.

Exactly the point, it doesn't reflect current implementation needs yet
has inconsistencies where any reasonable engineers can presumed the design
is beyond what you attempting to mandate for receivers.

> explanations why it is off the mark.

But there are multiple people who disagree with those explanations and 
agree Rolf is right on mark.

> We should be done.

We should of been done long ago. IETF needs to consider why you are 
having a hard time explaining away the security concerns for almost 5 
years now.

You need to rethink why reasonable compromising solutions offered 
should be ignored and rudely shunned out.  You need to consider good 
nature WG participant perspectives to help DKIM better fit receiver 
needs and considering ODID (and AUID) is compatible with the DKIM goal.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 08:51:03 -0700

> Sent: Wednesday, May 04, 2011 7:04 AM
> To: [email-masked]

There are two main fallacies that appear to be behind the arguments of a few people here:

(1) RFC4686 is gospel.  It isn't.  Its status is "Informative" which means it doesn't bind anyone to do anything.

(2) A working group is not entitled to change its mind about something based on experience.  It is.

Since RFC4686 was published, some of the consensus view of how this does/should/might all work has shifted.  There's nothing wrong with that.

If someone wants to undertake the work of publishing an update because it's seen as important, there are several of us that could assist with procedure, though it's unlikely to be done by this working group at this point.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 09:02:55 -0700

> If someone wants to undertake the work of publishing an update because it's seen as important, there are several of us that could assist with procedure, though it's unlikely to be done by this work…

My sense is that what Rolf is asking at its base is that the there is
a conflict between the two documents and it's not clear why they
exist, and which should be believed. If 4686 is inconsistent, then
we should make a case for why it's wrong and document that. It
may be process-wise "informational", but it served at the time as
a guiding document for the creation of 4871, and had working
group consensus at a time of extremely high scrutiny. We do not
have anywhere close to that level of scrutiny now, and as such
any changes made should be viewed with a very high level of
caution and scepticism.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 09:14:55 -0700

> Has anyone other than me bothered to generate and review the complete diff?

I've uploaded Murray's helpful effort to the DKIM site:

    <http://dkim.org/specs/rfc4871-to-bis02-diff.htm>

I had assumed that the complete diff would be unreadable, which is why I 
originally put up the incremental diffs.

However in looking through the complete diff, I'm surprised to discover that it 
is quite easy to see and evaluate all of the changes.

We really ought to stop responding to criticisms that provide no substantiation. 
  For criticism to be constructive, it needs to contain meaningful substance.

Complaining is easy; substantiating criticism takes effort.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 09:15:29 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, May 04, 2011 9:03 AM
> To: Murray S. Kucherawy
> Cc: Rolf E. Sonneveld; [email-masked]; [email-masked]

My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686.  (He can and should correct me if I'm wrong.)

If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance.

But if the point is to use RFC4686 to compel some change in something trying to get to DS (or even PS), that's a non-starter.

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 12:17:28 -0400

Dave CROCKER wrote:
> "Wholesale rewrite"?  Well, that should be easy for you to 
> document, given how convenient it is to point to the existing diffs.  
> The task when citing a problem with changes is to point to 
> /specific/ changes that are problematic.  That requires some work.
> 

Its absolutely amazing how the main points are just blow away. Wow!

#1 NEW - The key difference as so many others has stated is the 
MANDATORY mandate for the single output, SDID,  with a MUST design 
mandate for a futuristic single Trust Identity Assessor module.

#2 NEW - RFC4871bis introduces the AUID identity as a MAY for the 
trust module, *yet* this optional consideration is excluded from the 
RFC4871bis Output Requirements.

Incidentally, my concerns as well of many other implementors predated 
RFC4871 (2007 publication) with the drafting leading to the separation 
of policy and all policy related semantics from the base.  This was a 
major concerns cited by many including the prediction that policy will 
be not be completed as a standard.

The goal was to remove the Author Domain (ODID) from DKIM and move it 
to *purported* chartered proposed standard for policy, then called 
SSP. We completed WG consensus built requirements SSP document 
(RFC5017) and eventually ADSP (RFC5617).

In the name of protocol consistency and synergism with completed 
chartered RFC work products, it is only natural to expect the ODID 
MUST be part of the output identities for RFC4871BIS which should 
reflect all the RFC work that was done since RFC4871.  Instead we have:

#3 NEW: RFC4871BIS Output requirements that do not reflect any other 
work that as done, including this so called "DKIM Service Architecture."

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 09:40:23 -0700

Folks,

>      <http://dkim.org/specs/rfc4871-to-bis02-diff.htm>

apologies.  my html editor got sticky.  i guess it really liked the earlier diff.

The full diff that I meant to point to is:

    <http://dkim.org/specs/dkim-rfc4871-rfc-bis-diff.html>

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 09:47:37 -0700

> But if the point is to use RFC4686 to compel some change in something trying to get to DS (or even PS), that's a non-starter.

"Compel" and "non-starter" are not helpful. Everything past publication of
4871 should be viewed in the light that fewer and fewer people were paying
attention. The set of people paying attention now are extremely few, and
many of them have self-interest in revisiting and/or changing the previous
consensus -- taking advantage of the much smaller set of participants. Not
that 4686 and 4871 are some sort of ideal residing in a platonic cave, but
they do have the virtue that they were widely reviewed and in the case of
4871, implemented. We risk screwing things up with every edit; the law
of unintended consequences isn't being given the respect it deserves.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 09:48:25 -0700

> Sent: Wednesday, May 04, 2011 9:17 AM
> To: [email-masked]

Can we remain professional, please?  This flare for the dramatic only drags the group down further into the mire (as if that's possible).

> mandate for a futuristic single Trust Identity Assessor module.

I can't imagine any successful DKIM verifier module based on RFC4871 that didn't output at least the SDID and a status for the signature, for each signature.  Thus, saying so in RFC4871bis doesn't seem to me to be a normative change that breaks anything.

This is completely appropriate in another way: The SDID from a valid signature is the only thing that DKIM "proves".

> RFC4871bis Output Requirements.

It's true that the AUID is not listed as mandatory output, but that section very clearly states that a verifier could output other stuff, including the AUID, to a module that wants it.  I can't imagine any DKIM verifier module based on RFC4871 that would thus become non-compliant when compared to RFC4871bis.

But the AUID is only partially "proven" by DKIM; the local-part, for example, is potentially garbage, as is the subdomain.  So it makes sense not to make it a mandatory output of a security protocol.

So, please read the Output Requirements again and explain to me the basis for this claim.

> be not be completed as a standard.

And such separation occurred.  And it was good.

> (RFC5017) and eventually ADSP (RFC5617).

Right.

> reflect all the RFC work that was done since RFC4871.

No, that's not "natural".

> Instead we have:

-1.  RFC4871bis very clearly includes all the work that's been done, unless you have some other input that hasn't been revealed to date.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 10:10:40 -0700

> Complaining is easy; substantiating criticism takes effort.

44 pages of diffs. That is not by stretch of the imagination 
inconsequential.
I count at least two new normative changes -- in informational notes of all
places -- by scanning *half* the document, both of which are wrong. And that
does not count the normative change with Output.

Thanks for reinforcing my impression that this is a process run amok.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 10:13:36 -0700

> Sent: Wednesday, May 04, 2011 10:11 AM
> To: [email-masked]
> 44 pages of diffs.

Updating an RFC number causes a diff.  That's not a valid metric.

> does not count the normative change with Output.

Where are they?

> Thanks for reinforcing my impression that this is a process run amok.

Not so fast...

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 10:21:28 -0700

> Updating an RFC number causes a diff.  That's not a valid metric.

These aren't updates to just the rfc number though. This document
has been changing and changing and changing up until the weeks
before last call, and through last call. It's impossible to keep up with
unless it is your full time job, which it most certainly isn't in my case --
unless you can figure out how this relates to public key substitution
attacks in android market in-app purchases.

That is why I'm so alarmed.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 10:25:35 -0700

> Sent: Wednesday, May 04, 2011 10:21 AM
> To: Murray S. Kucherawy

Ah, you deftly avoided my question:

You said:

> >> I count at least two new normative changes -- in informational notes of all places -- by scanning
> >> *half* the document, both of which are wrong.

What were the two normative changes in informational notes that were wrong in the half of the document you scanned?

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 10:29:27 -0700

> What were the two normative changes in informational notes that were wrong in the half of the document you scanned?

It's because I didn't want to imply that those were the only two. It's just
what I found in my quick scan. But they were the advise about ignoring
signatures with sha1, and another saying you could ignore an l= *tag*.

And that's what I found in 15 minutes.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 4 May 2011 13:34:15 -0400

> Has anyone other than me bothered to generate and review the complete diff?

I have.  The changes to the parts that actually describe how to create a 
signature are tiny, and well contained, e.g. updating the punycode 
definition, making sha-1 more deprecated, clarifying that unknown options 
and flags are ignored, explicitly deleting whitespace around b= when 
computing signatures, notes that all bets are off if you start with an 
invalid message.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 10:43:15 -0700

> Sent: Wednesday, May 04, 2011 10:29 AM
> To: Murray S. Kucherawy

I can't recall the history of the first one, other than it being consistent with general IETF movement away from use of SHA1.  Perhaps someone else can comment there.

The advice that a verifier can ignore the "l=" tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 10:48:14 -0700

> If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't me…

My reading of the concern is specifically that the statement of DKIM's goal has 
been refined over time and that all that might be useful for the current 
document is to cite that fact and, perhaps, compare original versus current 
statements.  The appendix to do that would be very short.  It perhaps should 
cite the incremental changes across the sequence of wg documents and explain the 
salient meaning of the change, but in informative and not normative terms.

If there is more material at issue, what is it?

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 10:53:46 -0700

> I can't recall the history of the first one, other than it being consistent with general IETF movement away from use of SHA1.  Perhaps someone else can comment there.
Saying that receivers can ignore signatures with sha1 is a serious
difference. What does that do for interoperability if followed? Nothing
good is my guess. The advise I've always heard is "walk, but don't run"
away from sha1. Let's be real: DKIM's crypto guarantees are already low;
sha1 is the least of its weaknesses.

> The advice that a verifier can ignore the "l=" tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me.
You can't ignore the *tag*. That's the normative change. Whether you
ignore the *output* is another matter. But of course you can't ignore
the output because l= is "internal". Yet another problem.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 13:55:12 -0400

Murray S. Kucherawy wrote:

> Can we remain professional, please?  This flare for the dramatic 
> only drags the group down further into the mire (as if that's possible).

My apology but please view that take like "I'm giving up, You should 
read the specs correctly, Please Stop, We should be done. etc", none 
attributed anyone person, does make anyone giggle either.

> I can't imagine any successful DKIM verifier module based on RFC4871 
> that didn't output at least the SDID and a status for the signature, 
> for each signature.  Thus, saying so in RFC4871bis doesn't seem to me 
> to be a normative change that breaks anything.

I don't think u read this right.  Not saying it is bad - but its the
only receiver mandate at the expense of others.  No mandate can tell 
receivers what to do.  All options need to be presented.

> This is completely appropriate in another way: The SDID from a 
> valid signature is the only thing that DKIM "proves".

Ok, very good. It tells you the payoff value for SDID and its ok, to 
say its a mandatory identity receivers to look at. but its should be 
the exclusive one highlighted.

> It's true that the AUID is not listed as mandatory output, but that 
> section very clearly states that a verifier could output other 
> stuff, including the AUID, to a module that wants it.  

It clearly stated the obvious but not specific enough with DKIM 
related  semantics - "Being Specific is Terrific!"

> I can't imagine any DKIM verifier module based on RFC4871 that 
> would thus become non-compliant when compared to RFC4871bis.

I didn't make that claim.  What I said is that it hasn't learned.

> But the AUID is only partially "proven" by DKIM; the local-part, 
> for example, is potentially garbage, as is the subdomain.  So it 
> makes sense not to make it a mandatory output of a security protocol.

The problem here is that we are trying to dictate how to use it.  DKIM 
did it write in abstract terms and it should continue with that 
exposure.  You don't have to get into the details and that because 
AUID is still controversial, but making it available will prepare for 
the future.

Personally, I think the definition for it be the SDID domain or 
subdomain should be a MAY and to begin teaching verifiers that a 
mismatch should not invalidate the signature which is only a domain 
comparison check and not a hash bound violation issue.

> the basis for this claim.

See above.

> No, that's not "natural".

Well, who's right you or me?  I think its natural engineering to be 
protocol consistent among all integrated parts.

> -1.  RFC4871bis very clearly includes all the work that's been done, 
> unless you have some other input that hasn't been revealed to date.

I stated what I believe are the four minimal extracts for DKIM output 
and mail integration:

    signature verify status
    SDID
    AUID
    ODID

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 11:03:28 -0700

> Sent: Wednesday, May 04, 2011 10:54 AM
> To: Murray S. Kucherawy
> > The advice that a verifier can ignore the "l=" tag was in RFC4871, so
> > copying it to RFC4871bis doesn't seem like a problem to me.
>

But RFC4871 also said you could ignore the tag, so I don't understand the distinction you're making.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 11:10:09 -0700

> But RFC4871 also said you could ignore the tag, so I don't understand the distinction you're making.
Like I said, i only looked at this for a few minutes -- 4871 is wrong or 
sloppy
here too. But my other objection still stands: with the procrustean "output"
as it stand right now, an upper level entity would not be able to ignore
signatures with l= because that's "internal".

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 14:12:13 -0400

Dave,

Sure, you can add an new appendix to justify the inconsistencies but 
it still doesn't resolve the issue of not exposing the in-scope 
parameters to satisfy the DKIM Service Architecture and all receiver 
needs related to DKIM. The mandate to impose a certain behavior is 
unrealistic and does not represent current implementations.

This may not be an interest to you, but it to others.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 11:26:58 -0700

On 5/4/2011 9:47 AM, Michael Thomas wrote:
> The set of people paying attention now are extremely few, and many of them
> have self-interest in revisiting and/or changing the previous consensus --
> taking advantage of the much smaller set of participants.

Creative premise.  Your assertion is that folks outside the wg are not
monitoring it.

Given the continuing, intense attention to DKIM that is taking place at a
variety of vendues, such as MAAWG and some private industry groups, your
assertion does not match the experience a number of us have.

> On 5/4/2011 10:29 AM, Michael Thomas wrote:
>> It's because I didn't want to imply that those were the only two. It's
>> just what I found in my quick scan. But they were the advise about
>> ignoring signatures with sha1, and another saying you could ignore an l=
>> *tag*.

So apparently we've moved from a claim of normative changes to citation of
"advice", apparently with the claim that the advice is problematic.  Perhaps I'm
not understanding, but highlighting security differences, such as opening a hole
with l= or a protection weakness by using an older algorithm is not unusual and
it's difficult to see what is wrong with reminding an receiver that their
acceptance of data are voluntary.

>> And that's what I found in 15 minutes.

Does this mean that 20 minutes work is too much to expect from someone making
basic criticisms of months of wg effort?

Once again:  folks who participate seriously in an IETF working group and who
have substantive concerns have an obligation to provide the substance that
justifies the concern.  They are generally also expected to put effort into
proposing the details of a solution.

Such is the nature of constructive participation.  One can, of course, always
find creative excuses for not participating on that basis.

> On 5/4/2011 10:29 AM, Michael Thomas wrote:
>>> What were the two normative changes in informational notes that were
>>> wrong in the half of the document you scanned?
>>>
>>
>> It's because I didn't want to imply that those were the only two.

This is quite a remarkable premise for refusing to provide concrete substance.

I'm trying to imagine how a working group could ever make progress, were this 
premise prevalent.  Don't offer substance without providing a massive tome to 
cover everything that qualifies it enough to avoid misunderstanding what hasn't 
been said...

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 11:29:55 -0700

> Updating an RFC number causes a diff.  That's not a valid metric.

Since the diff is a side-by-side, it's worth noting that it's only 2/3 the 
length of the full document.

But indeed it's an example of a statistic that is objectively accurate and 
functionally misleading.

Just how onerous is it to look through that diff, enough to get a sense of the 
changes?  1/2-hour?  1 Hour?  Is that onerous, when seeking to put forward 
fundamental criticisms of months of working group effort?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 14:30:56 -0400

Hector Santos wrote:
> 
>> Murray wrote:
>> This is completely appropriate in another way: The SDID from a valid 
>> signature is the only thing that DKIM "proves".
> 
> Ok, very good. It tells you the payoff value for SDID and its ok, to say 
> its a mandatory identity receivers to look at. but its should be the 
> exclusive one highlighted.

Sorry, I read you wrong!  if you said:

    The SDID from a valid signature is the only thing that DKIM
    provides for TRUST assessment.

Then it is correct.  But it is not the only thing that DKIM proves and
trying to mandate this solve requirement on receivers is completely
inappropriate.

Now if we wish to be really truly DKIM complete:

    The AUID MAY be passed to Trust Assessors as well.

    The ODID MAY be used in advanced identity assessors such as
    Checking Signing Practices [RFC4686, RFC5595, RFC5016, RFC5617].

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 11:34:14 -0700

> the output because l= is "internal". Yet another problem.

So the issue is that someone might read it as "leave l=<value> out of what you feed to the hash" versus "hash it, but ignore what it's telling you"?

If so, I agree, we should fix that.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 11:36:46 -0700

> Sent: Wednesday, May 04, 2011 11:31 AM
> To: [email-masked]

It already says:

   The output MAY include other signature properties or result meta-
   data, including PERMFAILed or otherwise ignored signatures, for use
   by modules that consume those results.

Since the AUID counts as "other signature properties" and the RFC5322.From counts as "result meta-data", can we finally say we're done?

(I didn't think so.)

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 14:47:30 -0400

> assertion does not match the experience a number of us have.

Then one has to submit the question:

     Is the best interest of entire IETF mail community being served
     using a MAAWG and private industry group mandate to isolate
     DKIM to single identity trust assessment?

I suggest that the best interest of the majority which include small 
to mid operations, free or commercial is not being served.  If you 
want a solution for DKIM it needs to serve all parties of all sizes 
and it must not be done at the expense of security.

To quote a CEO of one such Marketing company [1]:

      Are we on the cusp of a customer trust meltdown? I don’t know.
      But we are dealing with ‘trust’ at a different level than I’ve
      seen before. Up to now, our trust conversations have centered on
      whether we can be trusted to use customer data as they’d like it
      be used. We’ve talked about trust relative to spam, data sharing
      and the like. These breaches take trust to a much more basic 
level —
      can we be trusted to keep our customer data safe and out of the 
hands
      of criminals who might do them harm. This is all about data 
security
      — something us marketers avoid thinking about, but now must because
      it has direct brand ramifications.

and his recommendation [2]:

    The framework I see for addressing this challenge is threefold:

    1. Rally the industry and articulate data security/best
       practice guidelines

    2. Encourage companies to apply those guidelines within
       their own environments

    3. Provide a collaboration forum for companies to
       discuss common threats and share best security practices

Security can not be ignored and want to give reasons for receivers 
across the board to accept these new roles, then you must present all 
outputs to help address all DKIM related evaluations, including does 
related to security.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 11:53:47 -0700

Seems like the replacement text should be something along the lines of:

>  l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
...
>          Considerations Section 8.  To avoid this attack, signers should
>          be extremely wary of using this tag, and verifiers might wish
>          to ignore the tag.

To avoid this attack, signers need to be extremely wary of using this tag, and 
verifiers might choose to ignore signatures containing it.

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 14:55:32 -0400

Missing citations for the quotes below:

[1] http://www.messagesystems.com/wordpress/?p=65
[2] http://www.messagesystems.com/wordpress/?p=69

>    level — can we be trusted to keep our customer data safe and out 
>    of the hands of criminals who might do them harm. This is all 
>    about data security — something us marketers avoid thinking 
>    about, but now must because it has direct brand ramifications.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 11:57:14 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, May 04, 2011 11:54 AM
> To: Murray S. Kucherawy
> > So the issue is that someone might read it as "leave l=<value>  out
> > of what you feed to the hash" versus "hash it, but ignore what it's
> > telling you"?
> >
> >  l= Body length count (plain-text unsigned decimal integer; OPTIONAL, ...

+1

As WGLC is closed, we'll have to wait for guidance from Barry about when we could make this change once consensus is reached.

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 15:05:42 -0400

Murray S. Kucherawy wrote:

>> Hector wrote:
> Since the AUID counts as "other signature properties" and the 
> RFC5322.From counts as "result meta-data", can we finally say 
> we're done?
> 
> (I didn't think so.)

Professional? :)

I can't be any more:

         Being specific is terrific!

Spell it out. Its not a mystery. Its in-scope, not harmful and gives a 
receiver a better reason to consider DKIM with greater usefulness 
regarding security which no one should take for granted - even 
marketers are finally get that point.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 12:07:38 -0700

> verifiers might choose to ignore signatures containing it.

Verifiers must not ignore them, assessors on the other hand may.
But assessors cannot because the existence of l= is not part of
the DKIM output. This results in an inconsistency in the protocol.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 12:08:48 -0700

> Sent: Wednesday, May 04, 2011 12:08 PM
> To: [email-masked]
> Cc: Dave CROCKER; Murray S. Kucherawy; [email-masked]

Either could.  It's an implementation choice.

If the verifier wants to enable the assessor to make the call, it's free to export "l=" information.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 12:13:01 -0700

> If the verifier wants to enable the assessor to make the call, it's free to

Verifiers declare a signature as valid or not.

This discussion is a very nice example of the difference between protocol vs.
implementation.  The protocol says l= is valid.  However a particular
implementor might choose to declare that any l= not covering the entire message
shall result in a failed verification. The same applies for verifiers detecting
use of sha1.

They are free to do that.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 12:13:04 -0700

> If the verifier wants to enable the assessor to make the call, it's free to export "l=" information.

I agree that it's an implementation issue. All of this is. But choosing
a single "output" formally makes that a no-no for the assessor, which
is a silly outcome. And it's but one silly outcome. What of the h= values?
How does an assessor know which ones were signed? That's a layering
violation according to -bis. Silly.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 12:24:05 -0700

On 05/04/2011 11:26 AM, Dave CROCKER wrote:
> I'm trying to imagine how a working group could ever make progress, 
> were this premise prevalent.  Don't offer substance without providing 
> a massive tome to cover everything that qualifies it enough to avoid 
> misunderstanding what hasn't been said...
>

More ad-hominems. I've written a DKIM stack. The first one in fact, followed
a week or so later testing with Murray. Call it an argument from 
authority, but
I at least have some experience in what subtle and seemingly inconsequential
wording changes can do to implementations.

44 pages of diffs scares the living hell out of me.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 4 May 2011 15:13:35 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, May 04, 2011 2:54 PM
> To: Murray S. Kucherawy

If this is the sort of advice we are going to give then we should just
deprecate "l=".

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 13:11:28 -0700

> Sent: Wednesday, May 04, 2011 12:13 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]; Dave CROCKER; [email-masked]

There's no proscription against providing those details if the verifier wants to export them.  The document is saying there is "one" required output, not "only one" output; it's a minimum.  And I think it's pretty clear about that.

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 16:48:54 -0400

Murray S. Kucherawy wrote:

> There's no proscription against providing those details if the 
> verifier wants to export them.  The document is saying there 
> is "one" required output, not "only one" output; it's a minimum.  
> And I think it's pretty clear about that.

But its not clear on the other outputs appropriate for the receiver to 
consider.

You can have a table:

    status  REQUIRED
    SDID    REQUIRED, MANDATORY for Trust Identity Assessor (see 2.7)
    AUID    OPTIONAL, see 3.11
    ODID    OPTIONAL for Checking Signing Process (see RFC5585)

I think what 3.9 should state these minimal DKIM related output 
purpose is to get a Security and/or Trust Evaluation.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 13:57:46 -0700

> Sent: Wednesday, May 04, 2011 1:49 PM
> To: Murray S. Kucherawy
> Cc: Michael Thomas; [email-masked]

And who gets to define "appropriate"?

It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol.

Protocols need to be kept simple.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 04 May 2011 23:12:20 +0200

Just a short note. Excuse me for not responding, I've been away from my 
office for a couple of hours due to the fact that we have today Memorial 
Day, at which we remember the WW-II victims. I'm catching up reading all 
contributions...

/rolf

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 14:11:09 -0700

> Protocols need to be kept simple.
4871 was simpler yet: it had no notion of an "output". It relied on the
developer to consider what was appropriate to deliver up the food
chain.

Manifestly this is very confusing. What is the "output" of IKE/KINK?
Patterned after DKIM, it would be the identity in the cert/ticket. But
it is profoundly the wrong question, which is what is leading to all
of these non-sequiturs.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 14:15:39 -0700

On 5/4/2011 12:24 PM, Michael Thomas wrote:
>> I'm trying to imagine how a working group could ever make progress, were
>> this premise prevalent. Don't offer substance without providing a massive
>> tome to cover everything that qualifies it enough to avoid misunderstanding
>> what hasn't been said...
>>
>
> More ad-hominems.

Oh?

Serious charge.

Please cite the specific text that qualifies as an ad hominem.

Please explain exactly what about it qualifies as an ad hominem.

> 44 pages of diffs scares the living hell out of me.

What number of pages would make you merely slightly uncomfortable?  What is your
limit?  Does it matter what the nature of the changes is?

d/

ps. It's worth noting that an unfounded charge of ad hominem behavior is,
itself, an ad hominem, since it focuses attention on a particular person, as
well as libeling them...

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 14:29:23 -0700

> developer to consider what was appropriate to deliver up the food

I should also expand that this entire situation started with Crocker
insisting that we must "choose" between between i= and d=
as The Output. It was a false dilemma then, and it remains
a false dilemma. And as with all false dilemmas it only causes
heat instead of light.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 17:30:35 -0400

Murray S. Kucherawy wrote:

>> Hector Wrote:

Well, who gets to define "Output Requirements?"

I will suggest it is both appropriate and required per RFC5585, 
RFC4686, RFC5017 and RFC5617.

> It's already been pointed out that we could list every 
> current tag's value and a pile of other stuff to pass on 
> to the next layer, which may or may not find it useful, 
> but that would make for an extremely messy protocol.

But that is not being requested.  You need to extract all the primary 
consideration that were discussed, developed, implemented over the 
years.  We have four RFCs, actually seven RFCs thats relates to DKIM

  rfc4686  Analysis of Threats Motivating DKIM
  rfc5016  Requirements for a DKIM Signing Practices Protocol
  rfc5518  Vouch By Reference
  rfc5585  DKIM Service Architecture
  rfc5617  DKIM Author Domain Signing Practices (ADSP)
  rfc5863  DKIM Development, Deployment, and Operations
  rfc5965  An Extensible Format for Email Feedback Reports

But in my opinion RFC5585 is the key document because, well, it has 
pretty pictures! :)   Ideally, you should list all of the above in 
section 1.1, but that is not being request - just the minimal extracts 
for receiver security and trust evaluations.

> Protocols need to be kept simple.

.... and secured and useful without losing your hair extracting this 
information for all receivers to consider.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 14:32:23 -0700

> a false dilemma. And as with all false dilemmas it only causes

Right.  It was all me.  Another ad hominem.  Nice.

But then I suppose the question is why you "should" have included that explansion.

Anyhow, its bad there wasn't any working group consensus on the changes.  I 
guess that means that the published, normative Update RFC was a violation of 
IETF principles and process.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 14:47:09 -0700

> Right.  It was all me.  Another ad hominem.  Nice.

History is a personal attack? Who knew?

> IETF principles and process.

One of the principles of DS is to remove things which aren't
implemented or serve no purpose. I think it's quite fitting to
ask that DS remove something that was added after the fact
in an errata update and has proved to be problematic. Does
the implementation report say who has implemented this
MUST? If not, why not? Could it be that it's untestable?

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 14:53:18 -0700

...
> History is a personal attack? Who knew?

Ahh.

Before using a term -- especially one with social and legal import -- it's worth 
doing the work of understanding what the term means.

As usual, wikipedia is a reasonable reference:

    <http://en.wikipedia.org/wiki/Ad_hominem>

d/

-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 05 May 2011 00:05:04 +0200

> Right.  It was all me.  Another ad hominem.  Nice.

No, it wasn't Dave. Mea Culpa. I had an off-list discussion with Murray 
which resulted in 
http://www.mail-archive.com/[email-masked]/msg15901.html.

/rolf

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 15:04:11 -0700

On 05/04/2011 02:53 PM, Dave CROCKER wrote:
> Before using a term -- especially one with social and legal import -- 
> it's worth doing the work of understanding what the term means.
>

Golly, Dave. I'm trying to figure out how history qualifies as ad hominem.
Maybe it's the guilt by association section that has you all riled up? I'd
think that you'd be proud that it was your idea. I'm all confused now.

Mike

PS: I remember very clearly at the interop at Alt-N when you brought this
       all up.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 18:11:17 -0400

Ah come on guys!  We all know what the problems are, we know the sides 
and what colors we wear.  Is it possible to come up with a compromise 
to solve this conflicts once and for all?

Dave, don't you want receivers to follow RFC5585 design?  If so, then 
what can't we get the Outputs described for that design to work?  From 
what I can see, there are four variables:

    status  REQUIRED

We have the REQUIRED/MANDATORY identity you want.  But you have the 
others too.

What is technically wrong with this?

-- 
Sincerely

Hector Santos

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 15:28:06 -0700

> Dave, don't you want receivers to follow RFC5585 design?  If so, then

RFC 5585 is not a 'design'.  It has a diagram that describes an overall service.

Also, the scope of its description is much larger than what is covered by the 
DKIM Signing specification.

> What is technically wrong with this?

It goes beyond the Update the working group and the IETF approved.

It also seems to confuse protocol issues with implementation issues.

d/

-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 05 May 2011 00:55:15 +0200

On 5/4/11 7:48 PM, Dave CROCKER wrote:
>> My read is that Rolf is objecting to RFC4871bis on the grounds that 
>> it conflicts with RFC4686.  (He can and should correct me if I'm wrong.)
>>
>> If his concerns would be satisfied by a change (perhaps an appendix?) 
>> that simply acknowledges some evolution in thinking based on 
>> experience since RFC4686 was published, I imagine that wouldn't meet 
>> with much resistance.
>
>
> My reading of the concern is specifically that the statement of DKIM's 
> goal has been refined over time and that all that might be useful for 
> the current document is to cite that fact and, perhaps, compare 
> original versus current statements.  The appendix to do that would be 
> very short.  It perhaps should cite the incremental changes across the 
> sequence of wg documents and explain the salient meaning of the 
> change, but in informative and not normative terms.
>

Well, I think you both are right in reading what my concern/objection 
against 4871bis is. And maybe you're also right in that RFC4871 wasn't 
that much different of RFC4871bis.

I think in the early days of DKIM most people assumed DKIM would become 
a protocol where:

    * the body hash and header hash, using various header fields,
      certifies the DKIM signature and
    * the DKIM signature certifies the body and header fields, that had
      been used to create the DKIM signature.

The current RFC4871bis defines a protocol where:

    * the body hash and header hash, using various header fields,
      certifies the DKIM signature and
    * the DKIM signature doesn't say anything about the body and header
      fields, that had been used to create the DKIM signature.

Well, if there is /real/ WG consensus that 4871bis is right in this 
respect, then so be it. But is there real consensus? Or is it just 
because of what Mike describes as "The set of people paying attention 
now are extremely few". Why don't we see any recent contributions from 
the authors of RFC4871? (except for Mike then).

It seems to me there are a number of WG participants (and I'm one of 
them), who regret the fact that RFC4871bis does not make the few 
additional steps required to achieve the expectations of the early days: 
a protocol that not only provides a DKIM signature (and an important d= 
payload) but also a protocol that certifies body and (some) header fields.

I fail to see why we don't take those one or two extra steps, to make 
DKIM a protocol with much more use potential.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 15:54:33 -0700

> Sent: Wednesday, May 04, 2011 3:11 PM
> To: [email-masked]
> Subject: [ietf-dkim] Output summary - Keep your Eye on the Prize!
> 

I'm game.  Let's play.

You want AUID and RFC5322.From added to the Output Requirements section explicitly.  At least two other participants disagree on either technical or procedural grounds.

So what's the compromise?  So far all you've done is repeat the suggestion without any changes, so the others repeat their position without any changes.  That's not a quest for compromise, it's a circular argument.

Try proposing something else, perhaps.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 16:07:18 -0700

> I think in the early days of DKIM most people assumed DKIM would become a protocol where:
> * the body hash and header hash, using various header fields, certifies the DKIM signature and
> * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature.
> 
> * the body hash and header hash, using various header fields, certifies the DKIM signature and
> * the DKIM signature doesn't say anything about the body and header fields, that had been used to create the
> DKIM signature.
> 
> Well, if there is /real/ WG consensus that 4871bis is right in this respect, then so be it. But is there real
> consensus? Or is it just because of what Mike describes as "The set of people paying attention now are
> extremely few". Why don't we see any recent contributions from the authors of RFC4871? (except for Mike
> then).

Any WG only has the people contributing currently upon which to build consensus.  We can't possibly hope to achieve something by requiring votes from past contributors if they've moved on or lost interest.

Keep in mind, too, that the document still has to go to the entire IETF and then the IESG for review and evaluation before it gets published.  It will get plenty of additional eyes on it to make sure we've done right.

> It seems to me there are a number of WG participants (and I'm one of them), who regret the fact that
> RFC4871bis does not make the few additional steps required to achieve the expectations of the early days: a
> protocol that not only provides a DKIM signature (and an important d= payload) but also a protocol that
> certifies body and (some) header fields.
> 
> I fail to see why we don't take those one or two extra steps, to make DKIM a protocol with much more use
> potential.

Suppose we do add a mechanism that allows a signer to make some assertion of the validity of the content of some header field or the body of the message.  Won't spammers just make those assertions in an attempt to make you believe something that's untrue?  I know I for one would be scared by a message that says "This really is a message from eBay.  Trust me!" unless I have some additional way to verify or trust the claim itself.

Signer assertions can't be trusted unless you know for sure you can trust the signer.  But DKIM has no way to tell you that.  So this is not something DKIM can specify.

Thus, I believe we had this debate at length and came to the conclusion that this creates more of a security problem than it solves.  Any trust in the validity of the content of a field or the body can certainly be made, but DKIM itself can't do it.  So we're back to protocol vs. implementation, and we can't do this in the base protocol, but maybe some higher layer or a later protocol extension could do it.  I'd be happy to work on specifying or conducting some experiments if someone has an idea about it; in fact, OpenDKIM already has the hooks needed to do so.

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 May 2011 19:22:05 -0400

>> to solve this conflicts once and for all?

I hope that means play nice.

> 
> You want AUID and RFC5322.From added to the Output Requirements 
> section explicitly.  At least two other participants disagree on 
> either technical or procedural grounds.

1) I have not seen any no arguments based on technical merits, or one
that didn't have an substantial proof.  Purely procedural and even SM
showed your opinion on procedural (for BIS work) was not quite IETF
correct.

2) There are at least four others (including myself) who agree with
the ODID proposal of both variable or one of them.

> So what's the compromise?  

Your ball.  You are the editor of the documents. Its up to you to
reduce the conflicts with proposed compromising text.  Murray, I am
not your problem as much you believe, insist it is.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 16:36:34 -0700

On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote:
>     * the DKIM signature certifies the body and header fields, that
>       had been used to create the DKIM signature.
>

Rolf,

By "certify" do you mean "assert that they are true/correct/something 
along those lines"?
DKIM doesn't make such assertions because there's no way absent a good 
deal more
infrastructure that a receiver should believe such an assertion. The 
addition of
ADSP adds one mechanism that allows a very narrow assertion about From to
the author domain be believable, but we certainly do not have anything 
beyond
that. If there was some verbiage in the security analysis, it is likely 
because
the precise delineation of signing protocol (DKIM) and policy protocol 
(ADSP)
was was not completely gelled at the time -- 4686 was put together mainly to
get past some process hurdles (imo) to form the wg, so it's pretty 
early. But
even then there was no intent to "certify" other header fields other 
than From.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 16:40:34 -0700

...
> Golly, Dave. I'm trying to figure out how history qualifies as ad hominem.

"Started with Crocker" points to the person.  Simply and directly.

Further, you are using the reference as part of a claim that there is a problem 
with a working group decision.

Hence you are attempting to pursue a criticism of that previous working group 
decision by asserting that it is somehow relevant to note and emphasize who it 
was that possibly initiated discussion.

I really do encourage you to read the definition of ad hominem in wikipedia.

> Maybe it's the guilt by association section that has you all riled up?

That you think it relevant who proposed an idea and that you think it might 
somehow create guilt is all the essence of ad hominem behavior, all of which 
repeatedly go very, very far beyond permissible IETF participation behavior.

And now that I've supplied an exemplar for explaining and justifying a claim of 
ad hominem, please note that you have not yet provided your own justification 
for the claim that you put forward.

Will that be forthcoming anytime soon?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 May 2011 16:54:22 -0700

On 05/04/2011 04:40 PM, Dave CROCKER wrote:
[]

I'll do Barry the favor of stopping this inane conversation, much
as it amuses me.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 17:28:47 -0700

Michael,

You've made a number of serious claims that you have yet to substantiate, 
including a personal one that otherwise resolves to libel.

That's rather more problematic than merely being 'inane'.  That you find such 
behavior amusing should further inform the proper handling of all this.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 May 2011 20:34:09 -0700

> Sent: Wednesday, May 04, 2011 4:22 PM
> Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
> 

You're not reading our replies then.  So here we go again, once more for the record, one of each:

Technical: The AUID is an unvetted value.  The local-part and the subdomain could be garbage.  It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated.  Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9.  The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary.

Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic).  Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2).  Only removing things is allowed.  SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it.  What he said and what I said are both correct.

> the ODID proposal of both variable or one of them.

I've only seen one other that supports the RFC5322.From as being a mandatory output.  So let's tackle that now too, for the record:

Technical: The RFC5322.From is an unvetted value.  The entire field could be garbage.  It's inappropriate; see above, same reasons.

Procedural: Adding a value, see above, same reasons.

> not your problem as much you believe, insist it is.

I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor.  Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often.  Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus up the chain of approval.  It is not up to us to encourage consensus or compromise for submitted ideas; it's up to the people making the submissions.  That's you here.  If you want the change, you do the legwork.

So far I don't see consensus that the RFC5322.From or AUID additions to 3.9 is an allowable change procedurally, or a supported one technically.  That's why it's not included.  You may of course appeal to the chair if you have different information than I do, but that's where it stands.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 05 May 2011 12:35:26 +0200

> Suppose we do add a mechanism that allows a signer to make some assertion of the validity of the content of some header field or the body of the message.  Won't spammers just make those assertions…

Excuse me for my poor English, I shouldn't have used the word 'certify' 
here. I'm not talking about validity of content. Were I used the word 
'certify' I mean:

if a DKIM signature verifies successfully, the consumer can be sure that 
the body of the message (or the part thereof indicated by l=) and the h= 
headers, used to construct this signature, has not been changed between 
signer and verifier, and there is a one-to-one relation between the h= 
headers and the corresponding headerlines in the header of the message, 
that leaves no room for ambiguity. And in my view neither the consumer 
nor the assessor should have to re-do the work of the verifier, to get 
the assurance, described in the previous line.

Agreed.

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 05 May 2011 12:48:48 +0200

On 5/5/11 1:36 AM, Michael Thomas wrote:
>> against 4871bis is. And maybe you're also right in that RFC4871 
>> wasn't that much different of RFC4871bis.
>>

see the message I just sent to the list.

/rolf

---

From: Michael Thomas <[email-masked]>
Date: Thu, 05 May 2011 06:29:25 -0700

> the assurance, described in the previous line.

Yes, that sounds right. Excuse me because the list volume has
been so high, but what's the problem? Btw, I _think_ the phrase
appropriate here is "data integrity".

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 May 2011 16:44:08 +0200

On 04.05.2011 21:13, MH Michael Hammer (5304) wrote:
>>   Considerations Section 8.  To avoid this attack, signers should be
>>   extremely wary of using this tag, and verifiers might wish to ignore
>>   the tag.
>>
>> To avoid this attack, signers need to be extremely wary of using this
>> tag, and verifiers might choose to ignore signatures containing it.

I thought we meant "ignore the value that this tag provides"; that is, fail
signatures only if the body length actually changed.

W.r.t. RFC 4871, we only removed the text suggesting to "remove text that
appears after the specified content length" (assuming it grew).  So we have a
very poor wording in both documents, pining for arguments among
opposite-minded implementers, one claiming that another is non-compliant.

> If this is the sort of advice we are going to give then we should just

+1: it was an error in the PS and the DS fixes it.

Alternatively we can allow it, warn, and expect implementers to code
heuristics that can discern attacks from regular footers.

We can't have both.

---

From: "John R. Levine" <[email-masked]>
Date: 5 May 2011 11:13:31 -0400

> heuristics that can discern attacks from regular footers.

Speaking as an implementer, I ignore l=, because the hassle of working 
around it and trying to guess how hostile any added content might be is 
vastly greater than any utility it has.  As I've often noted, there are 
about a hundred ways that a mailing list can break a signature, and l= 
deals (badly) with only one of them.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 13:01:53 -0400

Murray, your technical *subjective* reasoning is not convincing.

First, as for procedural issues, I have come to understand for bis 
work, how Hansen, Klensin and SM describes it. You do not seem to 
reflect the same advice and quite often in contradiction.

In regards to AUID, the only technical *non-subjective" protocol 
recommendation to consider is the one in section 3.11:

    Upon successfully verifying the signature, a receive-side DKIM
    verifier MUST communicate the Signing Domain Identifier (d=) to a
    consuming Identity Assessor module and MAY communicate the Agent or
    User Identifier (i=) if present.

It provides the non-subjective protocol technical justifications for 
both outputs to be part of the output requirements.  Nothing else need 
to be said. Its called Software Engineering. Choosing not to include 
it is a subjective implementation reason.

In regards to ODID, its a fundamental message header. Its technical 
history and importance should not be something to be explained. In 
DKIM, that fundamental messaging entity is reflected as the only 
single header requirement for signature binding and per RFC5585, 
RFC4686, RFC5017 and RFC5617 an essential part for security.

Most important of all:

DKIM can not mandate which is now a highly questionable protocol with 
highly subjective information in it with an highly isolated mandate 
for a mandatory single output with a MUST have requirement for a Trust 
Identity Assessor without *explicitly exposing* all the minimal 
outputs, especially when the default design excludes security protocol 
design considerations.

Protocol implementation is whats it all about and for RFC4871bis, it 
is for specific implementation design only.

If we want to exclude specific implementations, the Output 
Requirements needs to be more open with "DKIM Complete" information 
for receivers to better consider.

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 May 2011 13:09:45 -0400

Most important of all:

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 May 2011 16:07:00 -0400

Mike Thomas says...
> screwed the pooch. Put it back.

Mike, I have a lot of catching up to do, having been travelling for a
bit.  Some of that catching up involves dealing with complaints
(plural) about what you say on this list.  While I'm catching up and
figuring out how to handle all this, there's one thing I can directly
say up front:

Stop talking like this on the list.  Be professional and polite.
Avoid rancor.  Don't say things that people are likely to take as
implying that they're stupid, or have done stupid things.  That stuff,
along with phrases like "screwed the pooch", doesn't make your point
more effectively or forcefully; rather the opposite: it makes people
tend to ignore your underlying point because of the resentment you're
creating.  And it prompts them to complain to me.

Be civil, even if you're angry.  And if someone else irks you, don't
escalate it; stay civil then, too.

And this all goes for everyone, of course, though here I'm
specifically saying it to Mike.

Barry, as chair

---

From: Michael Thomas <[email-masked]>
Date: Thu, 05 May 2011 13:34:55 -0700

On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
> Technical: The AUID is an unvetted value.  The local-part and the subdomain could be garbage.  It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated.
>    

I don't think this is correct. The signer creates and signs the i= value,
so it's not "garbage", and it can't be "false" either. I don't even know
what false means in this context. It's just a value which  is guaranteed
to be within the to the d= domain's bailiwick.

Mike

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 May 2011 16:54:33 -0400

> deals (badly) with only one of them.

I agree, as a participant.  Nevertheless, we have consensus to leave
it in because of the stats Murray gave us on the usage (on the signing
side).

We certainly could deprecate it, and add something that says that
verifiers MAY consider a signature for which l= is less than the full
message length to fail verification.  Such a change should have been
proposed earlier in the process, but I won't consider it out of scope
if we have consensus to do that now.

And, of course, we can always add non-normative advice somewhere (but
I suggest NOT in 4871bis) that evaluation systems that use DKIM should
check l= against the message length when deciding what to do.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Thu, 05 May 2011 14:32:35 -0700

Agreed.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 5 May 2011 19:43:43 -0400

> it in because of the stats Murray gave us on the usage (on the signing

I agree we need to leave it in, but as I said, I would rather not offer 
advice about how to code around its limitations, not least because 
whatever advice we offer will be insufficient.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 May 2011 20:12:59 -0700

> Sent: Thursday, May 05, 2011 1:35 PM
> To: Murray S. Kucherawy
> > Technical: The AUID is an unvetted value.  The local-part and the
> > subdomain could be garbage.  It's inappropriate for a security protocol
> > to return a possibly false value in the context of saying something was
> > cryptographically validated.
> 

By "garbage", I mean "not guaranteed to have any useful meaning".

Think of how it might be used by someone seeking to avoid accumulating negative reputation.  The subdomain might not exist; it could be a string of random (though syntactically legal) characters.  The local part might not have anything at all to do with an email address or other login ID that's valid on the signer or author systems, and may be unique per-message meaning it can't be used as input to an assessor in a useful way.

So, I believe, it's essentially meaningless as far as the protocol can stipulate.  Assertions of its semantics thus fall outside of the base DKIM spec.

---

From: "John Levine" <[email-masked]>
Date: 6 May 2011 03:25:14 -0000

>so it's not "garbage", and it can't be "false" either.

Perhaps the word "stable" would be more applicable.  The d= value is
tied to the DNS, is relatively stable, and the verifier can check that
there's a key record in the DNS that matches the signature.  The parts
of the i= beyond what's in the d= are just an assertion by the signer
with no semantics, verifiable or otherwise, and are no more useful
than any other unverified assertion.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 May 2011 20:38:36 -0700

On 5/5/2011 8:12 PM, Murray S. Kucherawy wrote:
>> From: Michael Thomas [mailto:[email-masked]] Sent: Thursday, May 05, 2011
>> 1:35 PM
>>
>> so it's not "garbage",
...
...
> So, I believe, it's essentially meaningless as far as the protocol can
> stipulate.  Assertions of its semantics thus fall outside of the base DKIM
> spec.

It's worth noting that Murray said 'could be'.

But Murray's final paragraph has the essential points: within the scope of the
DKIM Signing specification, the receive-side has no way to determine what the
semantics of i= are, as we discussed at great length when formulating the Update
RFC.

But, then, folks on the list already know that.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 May 2011 00:40:52 -0400

> But, then, folks on the list already know that.

"We have here is a failure to communicate." - Cool Hand Luke

Dave,

This approach you have is an implementation conclusion.  It is not 
part of the protocol. The protocol clearly says in 3.11:

Therefore with no subjective consideration, no assertions, no 
philosophies, the protocol defines a process model of:

    trust = TrustIdentityAssessor(SDID [,AUID])

There is NO opinion about this! That is your DKIM Trust Protocol Model 
with a Mandatory SDID input and an optional AUID input.

In order for this to work, your 3.9 Output Requirement MUST expose 
those two parameters at the very least.  There is no assertions or 
opinions - thats the protocol you defined.

Now, when you begin to exclude it, then you mixing up implementation 
desires with subjective conclusion that really is not part of the 
protocol defined.  There is some subjective information notes about 
the value, but that has nothing to do with the protocol you defined.

To be consistent you have three protocol design tech writing choices:

   1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.

   2) Add AUID to 3.9 as an optional output

   3) Remove section 3.9

This is what happens when you add something in the last minute without 
any consensus.  It was just added - no consensus.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 May 2011 23:22:09 -0700

> Sent: Thursday, May 05, 2011 9:41 PM
> To: [email-masked]

Actually, using your notation, it's:

    trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]]]]])

How far do we really need to go here?

> those two parameters at the very least.

By saying "MAY ... other", I maintain that it already does.

>    2) Add AUID to 3.9 as an optional output

...or the solution I'm beginning to like:

4) Alter 3.11 to match 3.9.

> any consensus.  It was just added - no consensus.

After a short scan of the tracker item (#22) and the discussion thread, I found three people worked on the specific text and at least five (including those three) said they liked the result, versus one or two that disagreed.  That sounded like rough consensus to me and we were still within the WGLC deadline, so I incorporated the change.

Again, the Chair has the final say.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 May 2011 23:27:02 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, May 05, 2011 1:55 PM
> To: John R. Levine
> Cc: [email-masked]; Alessandro Vesely
> Subject: Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID "Originating Domain Identity"
> 

As I recall the document does say something like "acceptable to the verifier" and this is one of several local verifier policy examples that was meant to cover.  (Another, for example, is "Subject: wasn't included in the hash" which is an option in at least two implementations.)  I'm fine leaving it like that, or perhaps creating another appendix that lists common scenarios in this realm.

> check l= against the message length when deciding what to do.

Anyone sufficiently passionate about "l=" being deprecated can do that through other venues if we don't want to take that work up here.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 May 2011 23:47:58 -0700

> it in because of the stats Murray gave us on the usage (on the signing

For what it's worth, our stats show that it is in use on 3.58% of signatures received since August.  Pretty small, but far larger overall than "g=" which we removed in bis.  I don't know if the IETF has a hard-fast minimum adoption/use rate for cutting things so I don't know that I can draw a useful conclusion here.

---

From: "John Levine" <[email-masked]>
Date: 6 May 2011 12:37:09 -0000

> For what it's worth, our stats show that it is in use on 3.58% of
> signatures received since August.

Do you have enough data to know in how many of those 3.58% the body
wasn't the same length as the l= value ?

Looking at my much smaller archive, it appears that in most cases the
l= matches the body length so ignoring l= would make no practical
difference.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 07:05:31 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Friday, May 06, 2011 5:37 AM
> Cc: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] 23 again (sorry John) was Output summary -
> proposing ODID "Originating Domain Identity"
> 

Yes, that's here:

http://www.opendkim.org/stats/report.html#l_tag

You can see the count that have "l=" smaller than the final message size as well as the "l=0" ones, and how many of those passed or failed.

That's out of 155972 signatures that used "l=", and 4.36M total signatures observed, in just over eight months of data.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 May 2011 16:08:27 +0200

On 05/May/11 22:54, Barry Leiba wrote:
>> vastly greater than any utility it has.
> 

One place to put a normative "MAY" is in the last paragraph of section
6.1.3 "Compute the Verification".  E.g., replacing it with

   A body length specified in the "l=" tag of the signature limits the
   number of bytes of the body passed to the verification algorithm.
   Any added content, that is text beyond that limit, is not
   validated by DKIM, whether it was present at the time of signing
   or not.  Verifiers MAY apply whatever heuristics in order to
   determine the legitimacy of existing added content; in particular,
   verifiers MAY consider any added content hostile and hence return
   PERMFAIL (unsigned content) for signatures having l= less than the
   full message length.

If something like this is stated, the INFORMATIVE IMPLEMENTATION
WARNING of section 3.5 should be modified so as to avoid redundancy.
E.g. by replacing

   To avoid this attack, signers should be extremely wary of using
   this tag, and verifiers might wish to ignore the tag

with, say,

   To avoid this attack, signers should be extremely wary of using
   this tag, unless they know what heuristics verifiers will apply.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 6 May 2011 10:35:02 -0400

> That's out of 155972 signatures that used "l=", and 4.36M total signatures observed, in just over eight months of data.

Hmmn.  If my arithmetic is right, about 95% of l= signatures didn't cover 
the whole body, and only a few of those were l=0.  Your users must 
subscribe to different mailing lists than I do.

Regards,

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 06 May 2011 17:12:07 +0200

> subscribe to different mailing lists than I do.

John, the opendkim project gathers information from various sources, 
they're not necessarily the users of Murray and they're not necessarily 
subscribed to mailing lists. The statistics also doesn't tell which 
inbound mail is from legitimate sources and which inbound mail is from 
spammers/bad guys. Maybe the 95% you mention, are the spammers who try 
to abuse l= in DKIM...

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 08:24:41 -0700

> Sent: Friday, May 06, 2011 8:12 AM
> To: John R. Levine
> Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> 

Correlation against Spamassassin results is possible, though the data set is more limited because only a few reporting hosts include that extended data.  I'm not sure what this tells you but here it is:

+------------+------+------+
| l= present | pass | spam |
+------------+------+------+
|       4902 |    0 |    0 |
|        307 |    0 |    1 |
|      49265 |    1 |    0 |
|        775 |    1 |    1 |
+------------+------+------+
+------+------+------+
| l=0  | pass | spam |
+------+------+------+
| 3357 |    0 |    0 |
|  305 |    0 |    1 |
| 3386 |    1 |    0 |
|   14 |    1 |    1 |
+------+------+------+
+--------------+------+------+
| l= < msgsize | pass | spam |
+--------------+------+------+
|         4819 |    0 |    0 |
|          307 |    0 |    1 |
|        43539 |    1 |    0 |
|          768 |    1 |    1 |
+--------------+------+------+

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 08:31:42 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Friday, May 06, 2011 7:35 AM
> To: Murray S. Kucherawy
> > You can see the count that have "l=" smaller than the final message
> > size as well as the "l=0" ones, and how many of those passed or failed.
> >
> > That's out of 155972 signatures that used "l=", and 4.36M total
> > signatures observed, in just over eight months of data.
> 

Might not be list traffic.  But I have data for that too.  Count of signatures with "l=" that did or didn't appear to pass through an MLM:

+----------+--------------+
| count(*) | mailing_list |
+----------+--------------+
|    77246 |            0 |
|    78853 |            1 |
+----------+--------------+

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 May 2011 11:54:46 -0400

> subscribe to different mailing lists than I do.

of course, we don't all live in the same levine list world.

What I found in a quick grep scan of ~7000 list messages:

    137 used l= with some value
      3 used l=0 from the same source

More details:

   - Sorted down to 37 domains, 36 unknown, 1 known domain,
   - Except for 1 known, all mail from the 36 was spam,
   - 20 of them had the same patterns but different domains, and
   - the 20 used two signatures, sha1 and sha256

The collection were saved prior to verification so I don't know off 
hand if they failed or the actual body counts.

In my network of mail, I will say, l= is used by spammers blasting 
list mail to their collected emails addresses to spam.

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 May 2011 12:12:24 -0400

> How far do we really need to go here?

As far are the protocol technical specification says it is. However, 
isn't these additional parameters not part of a Trust Assessor 
functionality and are part of the validation functionality?  In 
principle, the RFC4871 process model prototyping using a dyadic FP 
(Functional Programming) methodology would be overall:

   MAIL.PAYLOAD    = MAIL_FEED()
   VERIFY.OUTPUT   = DKIM_VERIFY(MAIL.PAYLOAD)
   ACCESSOR.OUTPUT = DKIM_ACCESSORS(VERIFY.OUTPUT, MAIL.PAYLOAD)

In this summary prototype, MAIL.PAYLOAD provides all the inputs 
(RFC5322 message) for both verification and for any inputs required 
for any assessors in the process. The only new data would be included 
within the VERIFY.OUTPUT and ASSESSOR.OUTPUT namespaces.

With 3.9, VERIFY.OUTPUT is defined to be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID

Without 3.9, the technical reading extraction would be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID
   VERIFY.OUTPUT.AUID

and IMO, per RFCs 4686, 5016, 5617, 5585, 5863 it would be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID
   VERIFY.OUTPUT.AUID
   VERIFY.OUTPUT.ODID

To exclude AUID and/or ODID, it would be a subjective conclusion for a 
specific implementation mandate.

> ....or the solution I'm beginning to like:
> 

or take out 3.11 and like it was done for RFC5322.From, you can modify
the two references to the unfortunate technically incorrect sentence
in the abstract and section 1.2:

    DKIM separates the question of the identity of the signer of
    the message from the purported author of the message.

What "question" are we separating?  The association?  It would be 
technically incorrect given the binding requirement.

In lieu of ADSP, it may be a policy-based association separation but 
still an
DKIM-based association of authenticity.  As long as "Purported Author" 
is a fundamental requirement to be bound to the signature, it will 
always be an inherent association between the signer and author that 
can not be separated.

Maybe it can be change to a more functionally correct description:

    DKIM provides a mechanism which allows for the separation of
    the authorized association|relationship of the identity of
    the message signer from any other agent or user identity,
    including the originating author domain.

Anyway....

---

From: Douglas Otis <[email-masked]>
Date: Fri, 06 May 2011 09:34:08 -0700

> any consensus.  It was just added - no consensus.
I must agree with Hector on this point.  It seems the motivation to 
"simplify" DKIM has wrongly included removal of output information 
intended to be bound with the signature.  It would be like SMTP later 
deciding not to include trace information intended to be bound with the 
message.

While the "i=" may contain the email address of the author or the 
postmaster of the domain or simply an opaque tag, the meaning is NOT 
undefined.  Its meaning IS defined by the signing domain.  The whole 
point of DKIM was to establish a context for such information, 
especially information intended to be closely bound with the signature.  
Deprecating that aspect of DKIM overlooks many security aspects, and the 
valid and intended use of this information.  What this parameter had 
been defined should ensure against any interoperability issues, but 
perhaps deserves a warning that it NOT be used by third parties who are 
unaware of the signing domains definition of this field.  It would still 
be extremely useful within enterprise applications, for example.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 06 May 2011 09:36:46 -0700

> spammers/bad guys. Maybe the 95% you mention, are the spammers who try

Good luck with spammers trying abuse that. A naive filter wouldn't
know at all about l= but are well acquainted with spammers inserting
good looking text with spammy text. A dkim aware filter would be even
less impressed as the unsigned content would stick out like a sore
thumb. For all of the hysterical warnings in the spec, it would be
nice to hear about even ONE successful abuse. It's been, what, 5
years now?

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 11:24:45 -0700

> Sent: Friday, May 06, 2011 10:50 AM
> To: Murray S. Kucherawy
> > Might not be list traffic.  But I have data for that too.  Count of
> > signatures with "l=" that did or didn't appear to pass through an MLM:
> >
> That's just strange.  Most of the l= signatures don't cover the whole
> body, and half of those didn't go through a mailing list?

I suspect it's use of "l=" by a signer without regard to whether or not the mail is heading to an MLM.  For example, OpenDKIM's antecedent had that as an option; only the evolution to OpenDKIM allowed you to be more specific.

---

From: "John R. Levine" <[email-masked]>
Date: 6 May 2011 13:50:24 -0400

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 6 May 2011 14:43:09 -0400

> I suspect it's use of "l=" by a signer without regard to whether or not 
> the mail is heading to an MLM.  For example, OpenDKIM's antecedent had 
> that as an option; only the evolution to OpenDKIM allowed you to be more 
> specific.

Except that doesn't explain why l= doesn't cover the entire body.

Signing or verifying bug?  Clever spammer replaying signed mail and 
getting away with it?  Forwarders of some sort that add a footer but 
otherwise don't look like mailing lists?

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 11:50:38 -0700

> Sent: Friday, May 06, 2011 11:43 AM
> To: Murray S. Kucherawy

My guess is the third one.  The specification for what we decide is a mailing list submission isn't bulletproof, but is listed as:

- has a "Precedence: list" field
- has a "List-Id: field
- has a "List-Post:" field
- has a "List-Unsubscribe:" field
- has a "Mailing-List:" field

If there are other metrics that are easily detected, I could add monitoring for them and then cut off future reports at today's date, or something like that.

There's also the whole thing about "l=" is the post-canonicalization body count, not the actual full message byte count.  I'll double-check on that logic.

This won't change the "l=" use information though, just the pass/fail reporting accuracy.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 14:52:18 -0400

We've had a bit of discussion in this thread (and elsewhere) about
this, but I need to get a clear view of consensus.  Doug agrees with
Hector's note, below, and Dave and Murray do not.  I'd like to hear
from others within the next few days, about whether you think we
should make the change Hector requests or not.  I need to get a sense
of whether there's significant support for it.  Again, please keep
arguments to a minimum, so it's clearer to me what the consensus is --
we've had the arguments going for a while now.

Barry, as chair

---

From: "John R. Levine" <[email-masked]>
Date: 6 May 2011 15:09:22 -0400

> should make the change Hector requests or not.

Dave and Murray are right, Hector is not.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 06 May 2011 22:48:01 +0200

Hi, Murray,

> - has a "Mailing-List:" field

I assume this is a boolean OR list?

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 14:03:59 -0700

> Sent: Friday, May 06, 2011 1:48 PM
> To: Murray S. Kucherawy
> > My guess is the third one.  The specification for what we decide is a
> > mailing list submission isn't bulletproof, but is listed as:
> >

Correct.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 06 May 2011 23:47:08 +0200

> otherwise don't look like mailing lists?

or just "authoring MLM's" (see par. 4.2 of 
http://www.ietf.org/id/draft-ietf-dkim-mailinglists-08.txt) which 
probably use software that incorporates some (minimalistic) type of MLM 
which adds one of the headers, listed by Murray.

I notice I regularly get mail from marketing departments of my car 
dealer, smart phone provider, from Adobe, etc. that carry a 
'List-Unsubscribe' header and some of them carry a Precedence header. I 
wouldn't be surprised if the percentage of this type of messages is 
greater than the percentage of the 'classic' re-sending MLM type of 
messages.

Back to the topic of this thread: I don't think we can draw any 
conclusions from these statistics in relation to the description of l= 
in rfc4871bis. The current description in rfc4871bis works for me.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 May 2011 18:33:08 -0400

> in rfc4871bis. The current description in rfc4871bis works for me.

I would like to know the percentage of l=xxx where xxx equals actual 
body count.

If its very high, that will tell me there are many references to "l=" 
with text that sounds like its expected to be added.  I posted this here:

    http://mipassoc.org/pipermail/ietf-dkim/2011q2/016138.html

So if we wish to discourage "l=" useful, some of these text needs to 
be reworded, like this one in section 3.5

    bh=  The hash of the canonicalized body part of the message as
         limited by the "l=" tag (base64; REQUIRED).

It sounds like its expected and the REQUIRED is too close to "l=" 
which can throw someone off.  I suggested the change to be:

   bh=  The hash (base64; REQUIRED) of the canonicalized body part
        of the message. It is limited to the entire body length
        count or length explicitly set with the optional "l=" tag
        count value. If the hash is to represent the entire body
        with no expectation for additional unhashed text appended
        to the body, the l= tag SHOULD NOT be used. (See Section 9.1).

My post list all the references to "l=" for reading and setting.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 15:44:48 -0700

> Sent: Friday, May 06, 2011 3:33 PM
> To: Rolf E. Sonneveld

Assuming you mean "percentage of signatures using 'l=' where the signed length and the message length are the same", OpenDKIM's data shows that as 9008 out of 156524, or less than 6%.  Absent an error in the data, that suggests to me that when "l=" is used, it's being used because the mail is following a path through which it is likely to be extended.

> be reworded, like this one in section 3.5 [...]

I don't think the proposed text adds or clarifies anything that isn't already there.  The semantics and use of "l=" are pretty well defined already.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 09:01:23 -0400

> I don't think the proposed text adds or clarifies anything that isn't already there.
> The semantics and use of "l=" are pretty well defined already.

I agree.

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 09:59:36 -0400

> We are spending an awful amount of time on this l= issue, whether it should
> be pulled, keep it and explaining how bad it is and discourage usage.

Agreed.  I would like to deprecate it.  But we don't have consensus
for going that far, and I think we're too late in the process to get
ourselves mired in that.  What we're doing now is just short of
deprecating it -- saying that, well, you really shouldn't oughta use
it, without being normative.

> The 6% using "l=" needlessly is a red flag.

Yep.  Happily, we (where "we", here, mostly means Murray, but some
others as well) are collecting stats.

It's possible, later, for someone to create an individual submission
for "DKIM l= Considered Harmful", or some such, and perhaps if/when
someone ever moves DKIM to full Standard we can actually deprecate l=.

Barry, as participant

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 May 2011 10:07:59 -0400

Alessandro Vesely wrote:
> On 06/May/11 21:09, John R. Levine wrote:
> +1, since we don't know precisely what output is actually used.

Therefore, since we don't know, we discourage usage, exploration.  On 
the other hand, we encourage a single output for a MUST Trust Assessor 
Identity where by far, the majority of the receivers don't have.  I 
will venture using pareto, over 80% and most likely more 95-99%.

Wonderful.

I suggest we do know how what output is being used or would be used if 
enabled  or is a technical requirement:

1) Empirical Fact!

We know SDID is showing a very low payoff and very useless utility 
with a majority of DKIM mail coming from unknown signers and spammers

2) Current Implementations API Fact!

We know ODID is used for ADSP lookups, optionally or not.

3) Technical Fact!

We don't know if AUID is part of anything outside of it being adding 
as another signing bit, but it is WRITTEN in the technical 
specification as a MAY for Output.

I believe I am more RIGHT here than David and Murray and you.

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 May 2011 10:41:16 -0400

Volume tends to hide many important data points at the domain level. 
Many times its just 1-2 domains (and their implementation) that are 
showing how specs are being read/used.

My view in reading this complex document, many parts has become 
"sparse" with its technical information.  For the available tags to 
consider, most readers will use 3.5 as a quick guide and that is where 
the first warning should be highlighted.   It isn't highlighted unless 
you do a search for "l=" to see any other references for it.

So if we are not going to deprecate it and talk mostly about 
discouraging usage, the "Quick Guide" 3.5 tags sections should be the 
very first place with this important "tidbit."

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 07 May 2011 15:41:19 +0200

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 May 2011 09:39:52 -0400

Barry Leiba wrote:
>> I don't think the proposed text adds or clarifies anything 
>> that isn't already there. �The semantics and use of "l=" are 
>> pretty well defined already.
> 
> I agree.

Ok, no sweat.

(Note, there was more than one proposed text and not the only listed 
in the last post.)

However, for the record, I would like to provide my opinion:

We are spending an awful amount of time on this l= issue, whether it 
should be pulled, keep it and explaining how bad it is and discourage 
usage.

I would like to know why 6% of the mail use it but don't need it. That 
will suggest 6% of the potential DKIM Market are subject to "l=" 
exploit or %6 are just not reading it correctly. Should we wait until 
10%, 20%, etc?

Volume analysis needs to be broken down to domain analysis to see how 
DKIM is being used.

Consider that we don't know the domain break down of the 156524 
messages. So of the 156524, there are X unique domains, what percent 
of those use "l=" needlessly?  Was it  higher or lower than 6%? or was 
it just 1 or 2 domains?

---

From: Steve Atkins <[email-masked]>
Date: Sat, 7 May 2011 08:41:14 -0700

+1.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 May 2011 15:28:40 -0400

> we've had the arguments going for a while now.

BTW Barry,  the proposal I made was this:

    http://mipassoc.org/pipermail/ietf-dkim/2011q2/016282.html

Repeated here for those without editor URL launching support or disabled.

                  ----------------------
>> section explicitly.  

BTW, while RFC5322.From will satisfy requirements, I am proposing a
new ODID identity (RFC5322.From.domain) since that is whats already
extracted by APIs in order to do the current ADSP support.

I proposes the following:

3.9.  Output Requirements

     For each signature that verifies successfully or produces a TEMPFAIL
     result, the output of a DKIM verifier module MUST include the set of:

     o  The domain name, taken from the "d=" signature tag; and

     o  The result of the verification attempt for that signature.

|  Optional output are:
|
|  o  The Agent or User Identity (AUID) taken from "i=", if any.
|
|  o  The Originating Domain Identity (ODID). Verifier output
|     MAY consider ODID when no signatures or invalid signatures
|     are found.

     See Section 6.1 for discussion of signature validation result codes.

You might be able to figure out better text.
                           -----------------

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 May 2011 00:11:22 -0700

> Sent: Saturday, May 07, 2011 7:08 AM
> To: Alessandro Vesely
> Therefore, since we don't know, we discourage usage, exploration.

> with a majority of DKIM mail coming from unknown signers and spammers

Our data support the opposite conclusion; finding patterns in the data accumulated so far is proving to be rather useful, even though spammers are embracing DKIM and the AUID and RFC5322.From are not considered.

So I don't know who "we" is, but it doesn't include me.

> We know ODID is used for ADSP lookups, optionally or not.

I don't know what the "or not" means here.  ADSP only uses RFC5322.From, but ADSP itself is entirely optional.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 May 2011 00:02:16 -0700

> Sent: Saturday, May 07, 2011 7:00 AM
> To: Hector Santos

I don't know that I would "red flag" it so fast.  There are local policy options that can mitigate the damage, and the stats don't say whether or not those are in effect.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 08 May 2011 11:57:55 +0200

On 07/May/11 15:39, Hector Santos wrote:
> I would like to know why 6% of the mail use [l=] but don't need it.

One possible answer is that the signing agents have no clue about that
mail's destination.  The easiest way to configure DKIM in order to use
l= on some messages, is to enable it on _all_ messages.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 May 2011 10:03:18 -0400

>     Identity Assessor module.

I don't like making up a new name for what we already have.  I'd
rather just call it "the domain part of the 'From' address."

There's also the issue, in defining this, that there may be multiple
"From" addresses with different domain parts.  In a case like this:

   From: Paul Simon <[email-masked]>,
             Art Garfunkel <[email-masked]>

...which domain do we use?

>     by modules that consume those results.

I find this Mostly Harmless[1], but unnecessary.  As others have said,
it's clear that identity assessors can use any information they like,
and the contents of the RFC5322 From are included in that.  I don't
object to pointing out items that we think might be particularly
useful, but I don't think we should be calling it "output" of the
signature verifier.  And, really, advice about the identity assessor
should mostly be in the deployment document, not in the protocol
document.

In other words, as a participant, I prefer not to add this, but I
wouldn't fight strongly against it.

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 May 2011 10:08:49 -0400

Murray says...
> I don't know that I would "red flag" it so fast.  There are local policy options that
> can mitigate the damage, and the stats don't say whether or not those are in effect.

I think I would, and here's why:

Alessandro says...
> l= on some messages, is to enable it on _all_ messages.

I think Alessandro is right: there's likely no thought at all being
put into the use of l=.  Signing software is set up to use it because
it will make the chances that the signature verifies slightly
greater... with no consideration of the consequences.  Signers use it
because it's the default in the signing software, or because it's easy
to check the box to use it.  No one is thinking of why it might not be
a good idea.

This is all the more reason to deprecate it as soon as is practical
(though, again, I repeat: not here and now).

Barry, as participant

---

From: SM <[email-masked]>
Date: Sun, 08 May 2011 08:33:28 -0700

>of whether there's significant support for it.  Again, please keep

As I could not find any description of an interoperability issue in 
the arguments that have been made, I cannot support any change.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 May 2011 10:46:12 -0400

> rather just call it "the domain part of the 'From' address."

We already have an identity for it in section 2.3 - "Author's 
Organization"
and that is to mean a "domain".    We labeled all others with acronyms 
for easier modeling, why not ODID.

> ....which domain do we use?

This was already discussed over the years and many felt the first one 
(see next paragraph, but ADSP leaves it open, see ADSP Section 2.3 and 
3.0.   This is no different than having multiple 3rd party 
DKIM-Signatures with different responsible SDID signers.

Keep in mind the rarity of it too. The originating author is already a 
vetted input process at legitimate hosting systems, i.e. No 
*legitimate* System in the world allows a free FROM input field for 
users to freely enter not only just one unknown address but multiples 
as well.  The only ones are those catering to such anonymity have 
already long been the part and the source of the problem.

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 May 2011 13:09:52 -0400

> the arguments that have been made, I cannot support any change.

Section 1.1 says

    Readers are advised to be familiar with the material in [RFC4686],
    [RFC5585] and [RFC5863], which respectively provide the background
    for the development of DKIM, an overview of the service, and
    deployment and operations guidance and advice.

What do you think will happen when they read the DKIM Service 
Architecture, Security and Deployment Consensus Built Documents, all 
peppered with Signing Practices concepts?

Do you think they will wonder why 3.9 doesn't bother to mention 
anything regarding that large chunk in that pretty Software Engineer 
Process Model illustration?

Oh well.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 May 2011 10:13:37 -0700

> I suspect it's use of "l=" by a signer without regard to whether or not the mail is heading to an MLM.  For example, OpenDKIM's antecedent had that as an option; only the evolution to OpenDKIM allo…

You are certain to be correct.

In practical terms for the current world, what is the likelihood that a signer 
has any information about the 'type' of an email address?  How can a signer 
possibly know that an addressee is a mailing list???

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 May 2011 10:24:44 -0700

> rather just call it "the domain part of the 'From' address."

We might want to consider the benefits of consistency with existing documentation.

Email Arch (RFC 5598):

    Section 2.1.1:  Author - responsible for creating the message

    Section 2.2.1:  Originator - ensures that a message is valid for posting and
                    then submits it to a Relay

    Section 4.1.4:  From:    Author
                    Sender:  Originator

So what, exactly, are the semantics intended by this new term.

> I find this Mostly Harmless[1], but unnecessary.

Going to Draft is supposed to restrict changes to what is necessary, rather than 
what is whimiscally appealing to some folk.

There is already a problem with people's believing that DKIM "protects" or 
"validates" the From: field contents and that a DKIM signature implies 
assurances about that field, more than the actual data integrity from signing to 
verifying.

Adding a new term to refer to a portion of the From: field implies that there is 
an important need for the DKIM Signing specification to make that reference.

This feeds the confusion about the role of a DKIM signature.  That's not 
benignly "unnecessary".  That's actively counter-productive.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 8 May 2011 13:40:31 -0400

> possibly know that an addressee is a mailing list???

Our expert interface designers add yet another knob to the user friendly 
control panel, of course.

  http://graphics2.snopes.com/inboxer/graphics/rand.jpg

I have to say that way too much of the MLM document strikes me as 
overcomplicated workarounds to unlikely scenarios, all of which could be 
dealt with by encouraging lists to sign their outgoing mail.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 May 2011 10:45:47 -0700

On 5/8/2011 10:40 AM, John R. Levine wrote:
> Our expert interface designers add yet another knob to the user friendly control
> panel, of course.
>

How the heck did they get a photo of my living room???

But seriously...

> overcomplicated workarounds to unlikely scenarios, all of which could be dealt
> with by encouraging lists to sign their outgoing mail.

A document like this has a challenge to find the right balance between 
well-known vs. possible vs. likely issues.  The challenge is exacerbated, for 
scenarios that entail some complexity or, as with MLMs, mediation.

I think there are two reasonable ways to find the balance:

1.  State principals that are specific to the content of the draft and that give 
guidance about the scope and boundaries of what should be covered.

2.  Make specific suggestions for specific bits of text in the draft.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 8 May 2011 14:02:13 -0400

> 1.  State principals that are specific to the content of the draft and that 
> give guidance about the scope and boundaries of what should be covered.
>

Despite the valiant work that Murray has put into the MLM document, my 
preference, which I doubt has any hope of gaining consensus, would be to 
throw it away and replace it by one page that says

a) many lists break signatures, which isn't going to stop

b) so it would be nice if they signed their mail on the way out.

Everything else is either too marginal to be worth worrying about, or not 
a problem if a list's mail has a credible signature.*

Failing that, I don't see small changes making it any better, so just ship 
it.

Regards,

* - Yes, that includes whether you can believe the From: line. I'm 
agnostic about whether it's useful to include an A-R header describing the 
incoming state of the message.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Sun, 8 May 2011 11:13:14 -0700

> Failing that, I don't see small changes making it any better, so just ship 

+1 to all of that.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 May 2011 15:48:29 -0400

Dave CROCKER wrote:
>     Section 2.2.1:  Originator - ensures that a message is valid for 
>                     posting and then submits it to a Relay
> 

See RFC5585, RFC4686 and RFC5863. Which by the way has nothing to do 
with the author but the author domain (ODID).

We have long established the only single anchor we have in RFC5322 and 
one we must protect is the RFC5322.FROM and that is why is it the 
single only DKIM requirement for burning it into the signature.

Since the DKIM has nothing to say regarding missing signers, the 
security is lost and is thus an unsecured protocol design to now allow 
the ODID to be checked per RFC5016, RFC5617, RFC5585, RFC4686 and RFC5863.

> Adding a new term to refer to a portion of the From: field implies 
> that there is an important need for the DKIM Signing specification 
> to make that reference.

And it does in section 1.1 with the advisement for readers to be familiar:

> This feeds the confusion about the role of a DKIM signature.  

Too late. The existing confusion is to create (1) functional 
specifications and requirements and then ignore it in your (2) 
technical specifications, thus confusing (3) implementors, making (4) 
testing payoffs much harder to achieve  and (5) maintenance even worst 
to contain - your five phases of Software Engineering.

> That's not benignly "unnecessary".  That's actively 
> counter-productive.

See above.

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 May 2011 16:28:40 -0400

> a problem if a list's mail has a credible signature.*

Every time I read that, its just to too tempting to remind us of same 
outdated ill-advice as it was in RFC2821 section 7.1 par. 4:

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

And the only thing we learned in the 10 years to update it with 
RFC5321 ...

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against a user who is trying to fake mail.

is that the user is no longer ignorant!

I guess maybe we can rephrase it for DKIM:

    This specification does not further address the authentication issues
    associated with MLM other than to advocate that useful unrestricted
    resigning functionality not be disabled in the hope of providing
    some small margin of protection against an ignorant domain who is
    trying to submit fake mail.

Maybe we should remove "ignorant" so it still applies 10 years later.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 May 2011 08:57:41 -0400

> [email-masked]] On Behalf Of John R. Levine
> Sent: Sunday, May 08, 2011 2:02 PM
> To: Dave CROCKER

+1

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 May 2011 10:40:49 -0400

> [email-masked]] On Behalf Of Barry Leiba
> Sent: Saturday, May 07, 2011 10:00 AM
> To: Hector Santos
> should

Barry,

I'd like to request that we specifically test for consensus on
deprecating "l=" through the usual +1/-1 approach. No miring, just a
vote.

If we have consensus, great. If we don't have consensus then let's move
on. My concern is that if this is not addressed now it will not be
addressed in the future. My personal belief is that it should be
deprecated at this time.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 May 2011 07:28:59 -0700

...
>> Failing that, I don't see small changes making it any better, so just ship

Hmmm, it occurs to me that the folks doing this form of +1 might mean "ship it" 
or they might mean "preference for replacing with one-page doc or, failing that, 
ship it."

d/

-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 09 May 2011 16:28:12 +0200

> possibly know that an addressee is a mailing list???

Currently, it has to query the /time-distributed database/ brought
about by the spotty subscription reminders that MLMs send on April
fools' day and similar occasions.

Seriously, since it is a civic and sometimes legal duty to confirm
subscriptions, one may wonder why that database is not maintained by
means of present-day technologies.  Every MTA would then have a list
of mass mailers, cross-linked to its users, to be looked up when
whitelisting, signing, resolving complaints, and, occasionally,
attesting (un)subscriptions.

Forgive the OT.

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 9 May 2011 10:24:14 -0400

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 May 2011 07:56:52 -0700

> deprecating "l=" through the usual +1/-1 approach. No miring, just a

This isn't my vote, but a comment:

Oddly, I'm finding myself coming to believe that its use within a coordinated 
template for mediators might actually being helpful.  This assumes, of course, 
that the template can be specified and gain consensus, and that signers, 
verifiers and mediators all are willing to implement it.  Hence, this path 
involves significant effort.

One could argue that it's cleaner to drop it now and explore re-introducing it 
in the effort to develop that template.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 May 2011 15:35:05 -0400

Dave CROCKER wrote:
> Oddly, I'm finding myself coming to believe that its use within
> a coordinated template for mediators might actually being helpful.  

+1

> This assumes, of course, that the template can be specified and 
> gain consensus, and that signers, verifiers and mediators all are 
> willing to implement it.  Hence, this path involves significant effort.
> 
> One could argue that it's cleaner to drop it now and explore 
> re-introducing it in the effort to develop that template.

It is really just a matter of defining the current practical use cases 
today, highlighting it is only useful under limited cases.

 From a functional standpoint, the only purpose for the body length 
tag (LTAG) is when the author domain has a desire and intent to 
maintain the author's organization branding presence and originating 
message integrity by allowing for additional text to be added and with 
a no failure expectation, targeted at an intermediary with known 
behaviors.

However, the problem with LTAG is that it is not the only 
consideration and without target information, insufficient to maintain 
an expectation for survival.

In other words, from a technical standpoint, a consideration to use 
LTAG must come with other DKIM related factors:

     - Knowing the intermediary behavior,
     - Knowing what headers to sign, and
     - Knowing what content to avoid.

For example, in our MLM, the default options for creating a new list are:

    [X] Add Footer [...]
    [_] Add Header, if defined [...]
    [X] Use [list-name] tag in Subject: line
    [X] Add/Alter Reply-To set to list address
    [X] Keep Original To:
    [_] Strip Attachments. Exceptions [...]
    [X] Strip HTML
    [X] Add List-* Headers
    [_] Strip Dangerous HTML, Javascript code
    [_] DKIM Options
        [_] List only accepted valid DKIM submissions
        [X] Reject Restrictive ADSP Domains
        [X] Verify
        [X] Report
        [X] Sign
        [X] Strip original signatures

If a member knew how the targeted list distribution behaved, he would 
then know how to 100% survive sending DKIM signed mail with signing 
options:

     - Enable "l=" tag
     - Do not sign headers: Subject and Reply-to
     - Create only text/plain text

He can also survive it with DKIM options set:

    [X] DKIM Options
        [_] List only accepted valid DKIM submissions
        [X] Reject Restrictive ADSP Domains
        [X] Verify
        [X] Report
        [X] Sign
        [_] Strip original signatures

thus ending up with two valid signatures.

But if he also knew the message signature will be stripped and message 
resigned and was was ok with the the 3rd party signature, they 
probably may see they don't need sign mail unless the list required it.

So much of this has to do with the business use cases for the author 
domaina the DKIM signing service providers and how they are able to 
expose that information in general or contractual.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 May 2011 13:14:17 -0700

> in the effort to develop that template.

It sounds like what you're suggesting would be quite different from (and
more complex than) l=, and would have very different semantics compared
with the current numeric definition of l=.

Cheers,
  Steve

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 17:24:07 -0400

> deprecating "l=" through the usual +1/-1 approach. No miring, just a

Semantics first: we don't "vote" here.

OK, that taken care of, it's a fair request, because there's been a
lot of discussion about it.  We certainly have a good base of support
for deprecating "l=".

So I'll ask it this way, starting a new thread for it:
I determine from discussion that there's enough support for
deprecating "l=" to qualify as rough consensus *if* there's not much
objection to it.  It's the objection we need to gauge.  Please post to
this thread if you object to deprecating "l=" in 4871bis.  You may say
why you object, but please keep it brief, and let's not have a lot of
discussion of it here.  If there's enough objection to derail
deprecation, we will leave it alone.

You may also weigh in as objecting if you don't want to delay the
document by doing this.  I'll let this go until 25 May, or until
there's enough objection that we have our answer, whichever comes
first.  If we decide to deprecate it, I'll ask Murray to make the
edits, and then we'll need to have the working group approve the
result, so I expect that'll take another two weeks or so -- say, until
11 June.

Have at it.

Barry, as chair

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 17:30:30 -0400

> this thread if you object to deprecating "l=" in 4871bis

Sorry... I forgot to change the subject line.  Please do NOT register
your objection on this thread; do it on the "Issue: Consider
deprecating l=" thread.  Thanks.

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

---

From: "John Levine" <[email-masked]>
Date: 9 May 2011 20:07:11 -0000

>in the effort to develop that template.

This makes sense, but I suspect it's better to design it and use a new
tag with the semantics you need rather than to try to recycle l=

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 May 2011 15:36:03 -0700

> with the current numeric definition of l=.

In its entirety, yes.

My guess is that there is some benefit in a piece like (or the same as) l=, but 
the important difference is that it would be fit into an integrated mechanism, 
rather than just sit there piecemeal.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 May 2011 02:14:09 -0400

>> In practical terms for the current world, what is the likelihood that
>> a signer has any information about the 'type' of an email address?  
>> How can a signer possibly know that an addressee is a mailing list???
> 

Well, Dave's perspective is that of an independent (3rd party) free 
wheeling signer.  The issue at hand regarding the need to use the "l=" 
is that of an author domain signing his own mail and thus has already 
selected a s= value to use, its own or a provisioned independent 
signer domain.  But it the author domain doing all the picking, setup 
and signing - not the signer domain. Even if its the 3rd party, the 
author domain can still dictate what it wants (see the ending comment).

In our current rev1 DKIM implementation, the outbound edge MTA does 
the signing and it reads a setup file keyed on the From.domain or 
List-ID.domain.

That is how it knows what to sign and with what options per domain 
stream and this was the quickest and no MLM software change.  It was 
to handle the MLM list setups on our system or a customer system with 
the same software to handle its mailing list.

In Rev2 it will updated to handle external mailing list (inbound) 
using a "Mail Conference Type" factor and this is where the "l=" 
option MAY APPLY.

For example, for our API, the conference types are:

enum {
   mtNormalPublicPrivate,
   mtNormalPublic,
   mtNormalPrivate,
   mtFidoNetmail,
   mtEmailOnly,
   mtUsenetNewsgroup,
   mtUsenetNewsgroupModerated,
   mtInternetMailingList,
   mtFidoEcho,
   mtListServeForum,
   mtUserEmail,
   mtEND = 256
};

The operator can prepare "Internet Mailing List" conference where list 
traffic can be stored.  For this conference type, it also enabled a 
Reply Network Address.  For example:

    Name           : IETF-DKIM
    Type           : Internet Mailing List
    Network Address: [email-masked]

This conference can be accessible by online users, including by News 
Readers MUAs if the conference option is checked:

    [X] Publish as a Local Newsgroup

Any (access allowed) user reading the conference can create or reply 
and the mail is exported with a forced direction to the network address.

Now when we add DKIM, new options could be for a "internet mailing 
list" conference type:

   [X] Sign Mail
       [X] Use Body Length tag

With this option enabled, our edge MTA will now have the "setup" info 
to use the L= tag when signing it only for this specific network address.

Finally, it is not unheard off in the "outsource" or ISP/ESP/Anti-Spam 
mail service business to provide a list of user addresses for your 
system.  In fact, before we added better anti-spam stuff, we offered 
an utility to specifically export a complete or DIFF file of 
"acceptable users" for the hosting service to accept, do whatever to 
the mail if anything, and forward to mail to their smart host/MDA 
system.  This is how many early operators began to add Anti-Spam 
protection to their mail.

So for DKIM, a domain that wishes to outsource the signing operation 
to a 3rd party, can easily possibly to start using a similar manual or 
email automated method to send a full/change list of domains and 
addresses it wishes to be sign under specific options like a "l=".  In 
fact, the # of domains/addresses may even be part of the fee schedule 
for the service.  This will cater to domains with an fast DKIM entry 
point who do not wish the deal with the internal overhead and cost to 
setup/maintenance DKIM.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 May 2011 23:41:32 -0400

> we've had the arguments going for a while now.

I have the writeup almost ready for the IESG, and this issue has had
enough responses for me to get a clear sense:
We do not have consensus to make this change.  I'm closing issue #25
as "wontfix".  Thanks, Hector, for laying the issue out clearly, and
to others for reviewing and commenting.

Barry, as chair