Subject: [ietf-dkim] Whither 4871bis?

From: Barry Leiba <[email-masked]>
Date: Fri, 1 May 2009 11:54:14 -0400

This is the promised seed for 4871bis discussion.  Is the group ready
to move ahead with that?  Is the DKIM signing protocol ready to go to
Draft Standard?  Is there an update needed, with another cycle at
Proposed Standard?  Is there energy in the group to follow a 4871bis
effort through?

Please discuss this here, with the goal of deciding -- within the next
couple of weeks -- whether we should request a meeting slot in
Stockholm.

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 May 2009 12:44:12 -0700

> Proposed Standard?  Is there energy in the group to follow a 4871bis

1) Another Proposed Standard Cycle: -1; nothing to be gained, much to lose.
2) Draft Standard: -.1: not sure what we have to gain other than an IETF process
    Gold Star that nobody outside of the IETF standards potato world understands

As far as I can tell, DKIM deployment is going along just fine without any
further help from the IETF. Why risk screwing up a good thing?

		Mike

---

From: Tony Hansen <[email-masked]>
Date: Fri, 01 May 2009 23:11:47 -0400

I'm certainly ready to move forward with 4871bis. Yes, the protocol is
ready to go to Draft Standard. No, we do not need another cycle at
Proposed Standard. I think there's enough energy in the group to get
4871bis through.

As to why bother, with 16 errata to pore through, I feel that it is much
better to have one place to look for the technical spec instead of 17
documents.

	Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 May 2009 10:28:40 +0200

I'd like to break these into two points:

1.  On whether to do rfc4871bis at all

I tend to agree with Tony that we should do a -bis to clean up the 
errata.  If scoped as such it should be a very brief operation, taking 
no more than 6 months.

2.  On whether to move to draft standard

While I was initially in favor of this, I am now uncomfortable doing so, 
based on the lengthy debate we just concluded about errata.  To me the 
changes made by the document we just approved were sufficient enough to 
warrant all manner of process.  What's more, in that process we made 
some conceptual distinctions that I believe have not yet withstood the 
test of time.  We are not ready for draft.

I would recycle at proposed, if we are going to do anything at all.

Eliot

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 4 May 2009 15:53:11 +0530

> 1.  On whether to do rfc4871bis at all

-bis - yes. Definitely.

> based on the lengthy debate we just concluded about errata.  To me the

Qualified approval based on consensus gained in the -bis draft.

thanks
--srs

---

From: John Levine <[email-masked]>
Date: 4 May 2009 12:31:16 -0000

>errata.  If scoped as such it should be a very brief operation, taking 

Agreed, the world needs a description of DKIM and its warts in one place.

>2.  On whether to move to draft standard

I wouldn't bother.  It makes no difference in the outside world, so I'd
rather direct our limited time to -bis.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 04 May 2009 11:47:28 -0600

> better to have one place to look for the technical spec instead of 17

+1

Let's get bissy.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Mon, 04 May 2009 11:17:00 -0700

> errata.  If scoped as such it should be a very brief operation, taking 

If we do this, we need to be explicit about what changes there will
be allowed. If this is a "lets revisit every old argument under the
sun" we are doing a huge disservice to dkim.

Thus I think that Barry's formulation of the question is premature.
It should be "what would be do?" first followed ultimately with "should
we do it?". I suspect that lots of different parties have many different
ideas about "what should we do?".

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 May 2009 21:26:15 +0200

On 5/4/09 9:17 PM, Jeff Macdonald wrote:
> If I understand Suresh correctly, that the Standard draft would be 
> based on
> bis, +1.

Confusion has set in.  One moves to draft standard when the proposed 
standard has been stable for at least six months.  Given that we just 
essentially updated it, we can't possibly claim that.

Eliot

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 4 May 2009 15:37:13 -0400

> essentially updated it, we can't possibly claim that.

I wasn't under the impression that these were happening at the same
time. So, yes, maybe I'm confused.

-- 
Jeff Macdonald
[email-masked]

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 4 May 2009 15:17:31 -0400

>Qualified approval based on consensus gained in the -bis draft.

If I understand Suresh correctly, that the Standard draft would be based on
bis, +1.

-- 
Jeff Macdonald
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Mon, 04 May 2009 17:16:04 -0700

> better to have one place to look for the technical spec instead of 17

Maybe somebody can clarify whether you can roll errata from a PS and
go directly to draft. I gather from Eliot that you can't (?). Going
to draft is certainly a lot more palatable than another unproductive
romp through PS.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 May 2009 22:32:23 -0400

Procedure point:

> go directly to draft. I gather from Eliot that you can't (?).

My reading of things:
The 15 *real* errata won't stop anything.  They're really minor
changes, and could be rolled into an updated 4871 that goes in as
Draft Standard now.

The "update" document that we just submitted does not qualify in that
regard.  But it does "update 4871", so we could advance the updated
DKIM spec to Draft Standard six months after that document is
approved.

I don't think that's really a limiting factor, though.  It means that
if we want to bring DKIM base to Draft Standard, we could do it by the
end of this year, and that's likely as soon as we'd get to finishing
it anyway.

So the questions are whether DKIM base, with the recent update, would
be ready by then, and whether we care to do it.  Mike and John, in a
rare display of agreement, have both opined that "no one cares" about
it.  There is that thought: the IETF three-stage standards track is
meaningless, and that once something becomes Proposed Standard that's
good enough.

Barry

---

From: Jim Fenton <[email-masked]>
Date: Mon, 04 May 2009 20:31:45 -0700

> meaningless, and that once something becomes Proposed Standard that's

Having just reviewed yet another document referring to "recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM", I am reminded how little the community
outside IETF grasps the difference between Informational, Experimental,
and Standards Track, never mind the differences between Proposed, Draft,
and Full Standard.  So I agree that, largely, no one cares whether DKIM
is PS or DS.

I have been seeing significant uptake in DKIM adoption and am concerned
that, if we are seen to be making large changes to the specification,
we're likely to induce another round of waiting until we're "done" on
the part of implementers and adopters.  Regardless of how we describe
the compatibility between -bis and 4871, it's all about the perception
if large changes are being made.

I'd like to see us fold in the errata and update, waiting if necessary
for the update to meet the age requirement, and take the resulting
document to DS.  The main reason I advocate that we go to DS is that it
constrains the changes, and supports the perception that this is a small
change that will not upset current deployment and isn't worth delaying
deployment for.  Being able to describe the change as "an IETF process
thing" can be reassuring to those who might otherwise be worried about
technical changes.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 May 2009 08:50:21 -0700

Jim,

 > and Full Standard.  So I agree that, largely, no one cares whether DKIM

Taken as stated, your example actually implies that we shouldn't bother with 
standards effort at all, since the folk you cite consider anything with 'RFC' in 
the name to be a standard.  Are you suggesting that because some people do not 
understand (or care about) the IETF standards imprimatur, no one else does?

Ultimately, a standards process is whatever it is and the outside world chooses 
how to deal with it.  A standards group can only define itself as it sees fit 
and try to conform to that. Some people ignore whether a document is standards 
track.  Some ignore level of maturity.  Others pay close attention to these 
distinctions.

In the IETF, the purpose of moving to Draft is to formally declare that a 
specification has reached an additional level of maturity.

IETF standards differ from ITU standards, for example, by having maturation 
levels.  ITU standards, from one version to the next, can be dramatically 
different and fundamentally incompatible.  IETF standards cannot.

> if large changes are being made.

Basic concern about perceptions of substantial change is generic, serious and of 
course legitimate, IMO.

But how does it apply to what might be done to move the specification from 
Proposed to Draft?  What particulars are you worried about?

IETF rules are rather forceful in this regard. The only substantive changes 
permitted, for a specification moving from Proposed to Draft, is to remove 
unused or problematic features.  That is, the only substantive changes permitted 
make a specification simpler.

If, indeed, a feature is unused or problematic, then how will dropping it hurt 
adoption?  A simpler specification typically aids adoption, rather than hurting it.

And just to keep things real, can you cite some examples of the effect you are 
concerned about?

d/
-- 

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 May 2009 18:00:53 +0200

Dave,

Although it seems that I'm on the other side of the issue from Jim, I'm 
don't think the below is quite fair.

> And just to keep things real, can you cite some examples of the effect you are

If we accept the existing dogma that draft indicates "more stable" and 
that Proposed indicates "less", then Jim shouldn't have to answer the 
above question because he is operating under that dogma.  That's a more 
fundamental debate that should take place elsewhere (and has, to no 
one's benefit).

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 May 2009 09:08:09 -0700

Eliot,

Eliot Lear wrote:
>> And just to keep things real, can you cite some examples of the effect 
>> you are concerned about?
> 

Eliot, any of us can raise a concern.  There is an infinite number of them to 
choose from.  Many concerns that are logical and appear reasonable actually do 
not turn out to be hold true.  Lest we constantly be chasing fears that lack 
substance, experience is the filter to aid distinguishing among concerns.

Jim is clearly concerned about more that changing the label, even though the 
label is defined to mean 'more stable'.

Absent details and examples to substantiate it, how are we to take his concern 
and apply it to anything specific?

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 May 2009 09:11:21 -0700

On May 6, 2009, at 8:50 AM, Dave CROCKER wrote:

> If, indeed, a feature is unused or problematic, then how will  
> dropping it hurt adoption?  A simpler specification typically aids  
> adoption, rather than hurting it.
>
> And just to keep things real, can you cite some examples of the  
> effect you are concerned about?

Dave,

Deciding whether to place significant resources into services based  
upon DKIM can be stymied by those that don't understand how a feature  
_might_ be used productively once the services are in place.  Take for  
example the redefinition of the i= value that just took place within  
the last errata.  This represents a significant functional change with  
respect to information exchange.  This change can and likely will  
impact both email annotation services, as well as reputation  
services.   These services take time to develop.  Removing  
"problematic" features this early IS the problem.  The i= value is  
optional and is not required to match against any email-address.  The  
i= value only adds information, provided of course the definition for  
this field and its exchange is not changed.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 May 2009 17:08:59 -0700

Dave CROCKER wrote:
> Taken as stated, your example actually implies that we shouldn't
> bother with standards effort at all, since the folk you cite consider
> anything with 'RFC' in the name to be a standard.  Are you suggesting
> that because some people do not understand (or care about) the IETF
> standards imprimatur, no one else does?

I'm saying (recognizing this is well outside the scope of the working
group) that IETF has a problem in that it publishes informational,
experimental, and historic RFCs and many people outside IETF immediately
think anything with an RFC number is an "IETF standard".  That dilutes
the value of the IETF standards process and (talking like a marketing
person) the IETF "brand".

The distinctions between Proposed, Draft, and Full Standard are finer yet.
>
> Ultimately, a standards process is whatever it is and the outside
> world chooses how to deal with it.  A standards group can only define
> itself as it sees fit and try to conform to that. Some people ignore
> whether a document is standards track.  Some ignore level of
> maturity.  Others pay close attention to these distinctions.
>
> In the IETF, the purpose of moving to Draft is to formally declare
> that a specification has reached an additional level of maturity.
>
> IETF standards differ from ITU standards, for example, by having
> maturation levels.  ITU standards, from one version to the next, can
> be dramatically different and fundamentally incompatible.  IETF
> standards cannot.
>
>
> Basic concern about perceptions of substantial change is generic,
> serious and of course legitimate, IMO.
>
> But how does it apply to what might be done to move the specification
> from Proposed to Draft?  What particulars are you worried about?

Referring back to my message, I'm advocating that if we do anything, we
move to Draft Standard, and advocating that we not do another spin at
Proposed Standard.  So are we agreeing?
>
> IETF rules are rather forceful in this regard. The only substantive
> changes permitted, for a specification moving from Proposed to Draft,
> is to remove unused or problematic features.  That is, the only
> substantive changes permitted make a specification simpler.
>
> If, indeed, a feature is unused or problematic, then how will dropping
> it hurt adoption?  A simpler specification typically aids adoption,
> rather than hurting it.

Dropping unused features won't hurt adoption, so long as we handle the
backwards-compatibility issues properly (the dropped feature has
suitable defaults, and the IANA registries prevent re-use of previously
used names).  I'd need specifics to address the "problematic" case, though.

> And just to keep things real, can you cite some examples of the effect

The example here would be a specification that was updated at Proposed
Standard where that caused deployment to stall.  No, I don't have the
depth of experience in IETF to cite any.  But I feel that if we go
directly to DS, the constraints in that process will help assure that
doesn't happen.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 May 2009 22:07:31 -0700

> person) the IETF "brand".

Complaints about this date back at least 15 years.  The IETF has managed to 
muddle along in spite of the dilution.  Small observation:  Some people pay 
attention to the details of standardization and some don't.  Someone who thinks 
SPF is a 'standard' is probably not the target of formal standards effort, but 
that does not make formal standardization a wasted effort.

> Proposed Standard.  So are we agreeing?

I hadn't noticed anyone suggesting doing anything that cycled the specification 
at Proposed.  (The requirement placed on the Errata is different than we're 
discussing for the -bis effort.)

Have you heard otherwise?

>  But I feel that if we go

Yup.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 May 2009 11:31:44 +0200

> Have you heard otherwise?

That would be me.  Refer to recent messages, please.  The standard, 
IMHO, is not sufficiently baked, given the recent change.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 May 2009 08:25:10 -0700

Eliot,

I asked Jim a question.  He answered it.  His answers was completely different 
from yours, yet you were purporting to (again) answer on his behalf.

So while of course it's fine for you to have and express your own opinion, "That 
would be me" is not correct.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 May 2009 08:45:46 -0700

> would be me" is not correct.

If you want a private discussion, you should take it to private email.
You have no more standing here than anybody else to decide who is allowed
to comment on mailing list activity. And the assertion that Eliot is
"answering" for Jim is laughable on its face. Please stop this bullying.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Fri, 08 May 2009 10:03:04 -0700

Dave CROCKER wrote:
> I hadn't noticed anyone suggesting doing anything that cycled the
> specification at Proposed.  (The requirement placed on the Errata is
> different than we're discussing for the -bis effort.)
>
I don't know why it's my job to look this up in the list archives, but
anyway:

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011923.html , Eliot

> I would recycle at proposed, if we are going to do anything at all.

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011924.html , Suresh

> Qualified approval based on consensus gained in the -bis draft.
Which I think says "do -bis as Proposed Standard, then maybe go to
Draft".  Hope I have interpreted Suresh's comments accurately.

In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011925.html , John

> rather direct our limited time to -bis.
In http://mipassoc.org/pipermail/ietf-dkim/2009q2/011931.html , Jeff
Macdonald seems to agree with Suresh.

So, yes, I have heard otherwise.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 May 2009 19:38:46 +0100

So let me try summarise and ask a question.

I don't think I've seen anyone who wants to do more than
just roll up the existing errata into a bis document, possibly
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.

Please correct me if I've missed or misinterpreted postings
that wanted more change than indicated above.

I've seen folks interested in draft standard and some not.
As to that, my imperfect understanding of DS is that an
RFC needs to be 6 months old before DS is possible. So isn't
it the case that on the day that rfcNNNN (being 4871bis) is
published that it may as well be PS? If so, then I can't see
why anyone would object to interested folks then generating
the implementation reports required for DS (and I expect
that that'd be easier than with most RFCs given the wide
deployment of DKIM).

If so, then it may be that we do have consensus to produce
a 4871bis that rolls up the errata and makes editorial
clarifications that garner consensus along the way but
no more.

Does that sound about right?

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 May 2009 13:46:08 -0700

On May 8, 2009, at 11:38 AM, Stephen Farrell wrote:

> If so, then it may be that we do have consensus to produce a 4871bis  
> that rolls up the errata and makes editorial clarifications that  
> garner consensus along the way but no more.
>

Yes.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 May 2009 14:25:31 -0700

Is it too much to insist that anything we do here be reflected in the 
_charter_
so that there is no misunderstanding? As it stands, there is nothing in our
charter that says anything about any of this.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 May 2009 15:09:37 -0700

> or make other substantial changes.

I suggest we remove some of the features that
complicate deployment and/or add no value, and
I think a -bis draft is  a reasonable point in the process
to do so.

Cheers.
  Steve

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sat, 9 May 2009 05:12:47 +0530

> I think a -bis draft is  a reasonable point in the process

Trimming the fat would be one way to go, yes. And after that I'd
suggest devoting some energy to an implementation white paper, and
possibly another interoperability workshop to make sure various
implementations are completely up to spec with -bis.

To clarify my comment upthread .. move to a draft standard if you
absolutely need it as a draft standard,  But as John Levine pointed
out .. 'i wouldnt bother'.

In practice, I'll take a sufficiently mature -bis, especially when
there is running code implementing it, and it is interoperable with
other implementations.

--srs

---

From: John Levine <[email-masked]>
Date: 9 May 2009 00:01:46 -0000

>or make other substantial changes.

I'm with Steve, I'd like to deprecate the useless stuff.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 May 2009 11:10:59 -0400

> I'm with Steve, I'd like to deprecate the useless stuff.

So you have a itemized list of what you consider useless stuff?
Top 10, 5?

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: [email-masked] (Wietse Venema)
Date: Sat, 9 May 2009 12:04:30 -0400 (EDT)

> I'm with Steve, I'd like to deprecate the useless stuff.

I too am in favor of less complexity. We could start by
keeping only the attributes that must always be sent.

	Wietse

---

From: Steve Atkins <[email-masked]>
Date: Sat, 9 May 2009 10:03:17 -0700

> So you have a itemized list of what you consider useless stuff?

Sure. I'll post it in a new thread a little later today.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 May 2009 10:07:32 -0700

Suresh Ramasubramanian wrote:
>   And after that I'd
> suggest devoting some energy to an implementation white paper, 

Comments on the Deployment draft

    <http://dkim.org/ietf-dkim.htm#deployment>

are eagerly sought!

>  and

that could be interesting.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Sat, 9 May 2009 10:17:32 -0700

> that could be interesting.

Yup. Some validation of signature structure would be good too -
I think some signing implementations may be out of spec, but work anyway
because the crypto libraries used by the receiving implementations
are flexible enough to recognize the format, even if it's not the one
they're expecting.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Sat, 09 May 2009 11:52:40 -0700

> keeping only the attributes that must always be sent.

Talk about snatching defeat from the jaws of victory.

This is exactly why reopening this at this point is a stupid and
dangerous idea. There is nothing to be gained by this kind of
discussion except mass confusion, and making perfectly compliant
deployments broken.

    Mike

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 10 May 2009 00:54:04 +0530

> discussion except mass confusion, and making perfectly compliant

You can actually construct quite a rube goldberg machine with ALL the
dkim options currently.

Wouldnt hurt to trim fat unless you find useful operational cases for
those .. rather than theoretical situations.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Sat, 9 May 2009 13:08:33 -0700

> Sure. I'll post it in a new thread a little later today.

Summary of features to keep
===========================

   DKIM-Signature Header tags

     a: The algorithm used to generate the signature
     b: The signature itself
     bh: The hash of the canonicalised body
     c: Message canonicalization
     d: The signing domain
     h: List of header fields that are signed
     s: The selector
     t: Signature timestamp
     q: List of query methods (maybe - see notes)
     v: Version
     i: Additional information about the identity of the user or agent  
for which this message was signed

   TXT RR tags

     v: Version of the DKIM key record
     p: Public key data
     n: Human readable notes

Summary of features to consider dropping
========================================

   DKIM-Signature Header tags

     x: Signature expiration
     l: Body length count
     z: Copied header fields

   TXT RR tags

     g: Granularity of the key
     h: Acceptable hash algorithms
     k: Key type
     s: Service type
     t=y: Domain is testing DKIM
     t=s: Require that domain in i= and d= are the same

Other changes to consider
=========================

    Drop support for SHA1 entirely.

Discussion
==========

We're at a point where we have some experience with the current drafts  
and can usefully consider where the spec can be streamlined. As I  
understand the IETF process, this is something we're allowed, even  
encouraged, to do at this point (though if someone more familiar with  
IETF dogma than I could clarify that, that'd be useful).

The simpler a spec is, the easier it is to develop, test and operate,  
and the easier it is to explain to others. Any DKIM verifier needs to  
support all the parts of the specification, including the optional  
ones, in order to interoperate with all in-spec signers. So every  
feature of this spec, even the optional ones, carries a significant,  
on-going cost.

It's possible to add new features or reintroduce features that are  
dropped here through a separate spec layered on top of this one. In  
contrast, the core features retained here are mostly essential for any  
DKIM usage. Starting with a minimal spec and extending it as needed  
seems to be the approach that many successfully deployed protocols  
have used (as opposed to creating a large baseline specification, then  
specifying profiled subsets of it).

Discussion of features to keep
==============================

   DKIM-Signature Header tags

     a: The algorithm used to generate the signature
     b: The signature itself
     bh: The hash of the canonicalised body
     c: Message canonicalization
     d: The signing domain
     h: List of header fields that are signed
     s: The selector
     t: Signature timestamp

These are the core elements you're going to find in most any security  
approach of this sort. While a couple aren't absolutely essential (a=  
and c=) I don't think any of this subset are going to be controversial.

     q: List of query methods

I don't think q= is going to be controversial either, but I'm  
mentioning it separately as it currently only has one value, the  
default, it's unlikely to be extended, and if it were it would require  
a whole new RFC to do (which rather than extending the q= header,  
could add a "new" q= header). It doesn't hurt to keep it, though, as  
it's so simple.

     v: Version

I doubt this is actually going to be useful - I think any major  
evolution of DKIM to "version 2" is far more likely to be handled at  
the 822 level of adding a new header (allowing "DKIMv1" and "DKIMv2"  
to work in parallel, much as DomainKeys and DKIM do), and minor  
evolutions will need to be backwards compatible enough that it won't  
be meaningful to bump the version number. I could be wrong and it  
doesn't add any real complexity, though, so the cost of keeping it is  
very low

(For both v= and q= we should make sure any interop testing includes  
tests against "future" version of q= and v=.)

     i: Additional information about the identity of the user or agent  
for which this message was signed

This one is more controversial. It adds an awful lot of complexity and  
confusion about the semantics of what a signature is and quite a few  
people (myself included) would prefer it went away. But there are some  
potential uses for it, and some are already invested in it, so it  
seems unlikely we'd reach any consensus to drop it.

   TXT RR tags

     p: Public key data

This is the core of the protocol. Must have.

     v: Version of the DKIM key record

This is so simple that it's not worth discussing, even if it isn't  
technically needed.

     n: Human readable notes

Comments fields are often useful, even though they're not essential in  
this sort of protocol - especially given the limited space in the TXT  
record. The validator simply needs to know to ignore it, though, and  
the signer can make the choice to add it or not.

Discussion of features to consider dropping
===========================================

   DKIM-Signature Header tags

     x: Signature expiration

Expiration is a fairly common feature in signing specifications. But  
DK and DKIM are different in that the public key is not distributed to  
others, it's always under the control of the signer. Does this add  
anything that removing the DNS TXT record doesn't do? Is it used? Is  
it necessary?

     l: Body length count

This opens up a whole host of security issues, related to being able  
to change the rendered content of the message entirely after signing  
without breaking the signature. Removing it would remove a security  
hole you can drive a bus through. Is it being used? Are there any  
situations where it has proved useful?

     z: Copied header fields

Has this been useful? Is it likely to remain useful beyond a testing  
phase?

   TXT RR tags

     h: Acceptable hash algorithms

The spec needs to define the supported set of hash algorithms. There  
may be some value in a signer being able to state that they're using  
an algorithm that isn't supported, perhaps.

But unless there is a viable attack such that an attacker can craft a  
message that validates correctly against the domain owner public key  
using a hash supported by the spec (sha1 or sha256), without access to  
the domain owners private key, then there's no need for this to be in  
the TXT record.

     k: Key type

Much the same as h=, with the added issue that there's only one  
possible key type right now, and if there were a need for k= in the  
future it could be added in the same RFC that adds support for  
anything other than RSA.

     t=y: Domain is testing DKIM

A "test flag" is a little like the version field, except there's much  
less history of it's use in Internet standards. It isn't that useful,  
and may cause problems.

It seems a questionable choice to define something into a protocol  
that's almost immediately useless. Testing takes place only during  
startup, then everyone has to support it forever, even though it's  
never used again. In the case of DKIM it's also unclear how this would  
be useful, as there's no obvious way for a receiver to communicate to  
a sender the result of a DKIM validation in testing mode other than an  
arrangement outside of the protocol - in which case the testing flag  
wouldn't need to be part of the protocol.

Is anyone supporting t=y in a DKIM validator? What does it do in terms  
of delivery and communication with the sender that's different to  
normal non-test usage? And is it useful?

     g: Granularity of the key
     s: Service type
     t=s: Require that domain in i= and d= are the same

All three of these exist to ask the DKIM validator to compensate for  
the domain owners lack of control over usage inside the domain owners  
area of control. They don't belong in the basic DKIM signing mechanism.

If they're thought to be useful to identify and control different  
aspects of use, what are they, or what are they thought likely to be?

Discussion of other changes to consider
=======================================

    Drop support for SHA1 entirely. It's beginning to look  
cryptographically very dubious, and is being dropped by pretty much  
everyone else. Even if the attacks against it don't affect the way  
it's used in DKIM it seems unwise to suggest it be used at all. At the  
very least it seems a poor "marketing" move to include an algorithm  
that's been dropped by most everyone else as insecure before this spec  
is finalized.

    "Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.  
Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa- 
sha1." might provide enough wiggle room to allow existing code time to  
migrate away from SHA1.

Cheers,
   Steve

---

From: Tony Hansen <[email-masked]>
Date: Sat, 09 May 2009 20:49:44 -0400

Regarding the use of sha1 vs. sha256, I did a search of messages I've
collected in the past few years that have dkim signatures.

2008	rsa-sha1	1016
2008	rsa-sha256	1525
2009	rsa-sha1	1983
2009	rsa-sha256	1932

These are just messages that have arrived in my inbox. It's just a data
point.

Regarding Steve Atkin's suggested reworded text:
    "Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.
    Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using
    rsa-sha1." might provide enough wiggle room to allow existing code
    time to migrate away from SHA1.

I'm not sure we can downgrade verifier support for sha1. However, I
definitely agree that we could downgrade signing support for sha1.

	Tony Hansen
	[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 May 2009 21:51:48 -0400

> discussion except mass confusion, and making perfectly compliant

Thats what happens when you have mixed disciplines and a rough 
consensus by osmosis decision making process.

-- 
Sincerely

Hector Santos

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 10 May 2009 07:41:04 +0530

+1

I dont see verifier support for sha-1 going away for quite a while due
to legacy installations.   Downgrading or entirely removing (except if
a flag is explicitly set, say) SHA-1 signing is certainly an option.

thanks
--srs

-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 May 2009 22:54:47 -0400

Good starting point list.

> Summary of features to consider dropping

Removal of these would be a show stopper for me. In fact, overall, 
anything that is SECURITY related should be protected from removal 
proposal.

>      t=y: Domain is testing DKIM

+1 Definitely this because that was suggested many moons ago - nothing 
can be in perpetual testing and should not be used as an excuse for 
failure.

>      t=s: Require that domain in i= and d= are the same

Until POLICY is resolved, I do not suggest removing this.

> Other changes to consider

The only technical reason to keep this is that SHA256 is not 
guaranteed to be supported on all Windows station which would be a 
concern for Window ISVs.  However, that was more problematic in the 
past because Microsoft made SHA256 and "added value feature" for their 
Security layer i.e. you had to update Windows to Vista.  But they have 
been made aware that SHA256 should be  part of the OS security layer 
and via service packs have provided in Windows OS.

So its less of an issue today to use SHA256 exclusively. Should SHA1 
be dropped?  I personally wouldn't vote to remove it.

I don't think this is valid reason for dropping SHA1.  First, there is 
an overhead penalty using SHA256, second, as indicated above, although 
MS did update their OS to include SHA256 support, from a verificattion 
standpoint, you are shooting at darts (will the client support the 
signature hashing?) and it might be a technical solid idea to have a 
common denominator available in the short term for implementations.

Keep in mind that not everyone using OPENSSL, so unless OPENSSL is 
made part of the Required DKIM Resources, you can't enforce an method 
that simply may not be available on the Windows CLIENT machine.

>     "Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.  

Huh?  The verifier will be driven by whatever the signature has and is 
capable of supporting. The idea that there might be half-baked DKIM 
verifiers is a bad taste for encouraging DKIM signers.

> sha1." might provide enough wiggle room to allow existing code time to  

There should be no MATCHING issue born from any of the this.   DKIM 
signer and verifiers both must play by the same signing rules.

I understand this is an issue.  And it might be ok to stick with 
SHA256, but I personally do not see this as a barrier to adoption.

What we should be looking at is WHY, hardly anyone, but only a few 
systems are using DKIM.  I seriously doubt it is the hashing method or 
  the expiration or any of the other suggested tags to drop.

The reasons I have not added DKIM into our commercial software is:

  - Lack of a visible payoff.
  - Lack of policy, what I call the DKIM Domain Ownership Problem
  - Cost of implementation (revamping of existing software)

I personally believe we should not be doing BIS with the idea of 
REMOVING major parts of it.  Today, we live in an integrated world, it 
is not the 1980s where each protocol must  be isolated fully. No, it 
is 2009 and the protocol needs to have integration ideas - WHY is 
someone going to bother to sign, why is someone going to verifier, and 
quite frankly, we have handicapped the both the signer and verifier 
with poor POLICY and DOMAIN Ownership engineering management for the 
past 3-4 years.

There is simply no strong incentive to implement DKIM. Streamlining 
it ala ADSP isn't going to improve adoption rate.  This is a Total, 
Big Picture problem.

-- 
Sincerely

Hector Santos

---

From: Mark Delany <[email-masked]>
Date: Sat, 9 May 2009 20:15:59 -0700

> anything that is SECURITY related should be protected from removal

Do you mean anything that is security related or do you mean any thing  
that improves security? You're not being very precise.

As I understand it l: reduces security because it introduces wiggle- 
room and x: seems only to offer theoretical benefits that are far more  
concretely established via key revocation in the DNS.

Furthermore, x: is largely meaningless if you accept that DKIM is a  
temporal authentication mechanism, which it has always intended to be.

Mark.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 10 May 2009 08:06:30 +0200

> I'm with Steve, I'd like to deprecate the useless stuff.

I like deprecating useless stuff, but before we do that I would like to 
see broader implementation, and again, specifically in mailing list 
managers, before we decide what is useless.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 09 May 2009 23:28:42 -0700

> managers, before we decide what is useless.

      "The simpler a spec is, the easier it is to develop, test and operate,
and the easier it is to explain to others. "

Deprecating what is non-essential facilitates adoption.  You can't facilitate 
that adoption if you wait until there is more adoption.

Rather than cycling around on a conceptual point, try considering the specific 
reasons given to deprecate each of the tags and see if there are 
counter-arguments for why the tag is actually really important.

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Sun, 10 May 2009 09:11:49 +0200

On 5/10/09 8:28 AM, Dave CROCKER wrote:
> Deprecating what is non-essential facilitates adoption.  You can't 
> facilitate that adoption if you wait until there is more adoption.

I agree.  Understanding what's non-essential requires time and 
consideration of use cases, one of which I have mentioned.  We can talk 
about tags in that context, but I would like mailing list manager 
developers to be part of that conversation, since theres' is the biggest 
unfilled gap.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 10 May 2009 12:52:48 +0530

> developers to be part of that conversation, since theres' is the biggest

So ok - I am reasonably sure several people are familiar with Chris
Knight, Barry Warsaw etc and might want to ping them, unless they're
already on the list?

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2009 09:21:02 -0400

> that improves security? You're not being very precise.

Mark you know what I mean.

Overall, I would be -1 for removing any current feature designed to 
improve security, control aspects of the message that are related to 
the validity of it.

> room 

True.  Maybe I was thinking l is the original pre-cl4n byte count of 
the message, not the signed count, so anything over the original 
should be considered invalid.

> and x: seems only to offer theoretical benefits that are far more  

Thats one thought. But if you are not going to be revocation keys, you 
still might want to have a time limit.  You are making the assumption 
that people will be revoking keys for the purpose to expire messages. 
  Its a good policy, but IMO after a while that is going to get 
tiresome for many when all they wanted to do is put an x= on the 
message.  Its like passwords, it would be nice if users change their 
password regularly, but their don't so many systems force it with 
password expirations.  Consider also it is does the verifier a favor 
too. Whether or not x= matches the key expiration period, the verifier 
can save lookup overhead for those messages that expired.

Overall, I don't see these as candidates for complexity. These are 
simple low overhead checks, especially x= because if the message 
expired there is no need hashing overhead - immediate reject.

Anyway, thanks for your feedback.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2009 09:34:21 -0400

> developers to be part of that conversation, since theres' is the biggest 

We are mailing list software developer

    http://www.santronics.com/products/winserver/ListServe.php

and these tags are not whats keeping us from adding DKIM to it.  If 
Dave thinks reducing DKIM is going to help the adoption issue, well, 
that just goes to show how off base he has been on DKIM.

-- 
Sincerely

Hector Santos

---

From: "Siegel, Ellen" <[email-masked]>
Date: Sun, 10 May 2009 19:12:01 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wietse Venema
> 

 +1

Ellen

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 May 2009 21:38:19 -0700

Murray S. Kucherawy wrote:
> For the sake of trying to find some compromise, can we do what we did 
> with the AUID/SDID debate and indicate which tags an implementation MUST 
> support and which ones it MAY support?

Always a reasonable goal.  But what makes that sort of exercise challenging, 
here, is trying to keep signers and verifiers in synch about what they *both* 
support.

For example, saying MAY on l= could mean that a signer might choose to 
implementer and a validator might not.  Hence, no interoperability.

If the use of a tag by a signer, with non-support by the verifier, will prevent 
interoperability, then I think it can't be optional.

This does not negate the benefit of what you are suggesting, but it does make it 
more difficult.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2009 21:15:35 -0700 (PDT)

> could add a "new" q= header). It doesn't hurt to keep it, though, as

If we drop it, it would just get added back in later when some other key 
publication mechanism is needed.  That said, I'd rather leave an unused 
but potentially useful hook in there versus removing it now only to have 
it added back in later, possibly poorly.

> situations where it has proved useful?

Despite the warnings we've posted about it, at least one site has 
contributed patches to our implementation that extends its basic utility. 
That means there's at least a little demand for its use.

> Has this been useful? Is it likely to remain useful beyond a testing

Yes, it has proven useful in debugging specific installations, not simply 
specific implementations.  -1 on removing it.

> normal non-test usage? And is it useful?

Yes, we do.  If a message fails and a customer has actually (against our 
defaults and recommendations) configured the filter to reject mail that 
fails signature validation, the "t=y" key drops the "fail" result to a 
"neutral" one and avoids rejection.

I don't know if that's actually useful behaviour (our user base has been 
slack when it comes to replying to such inquiries), but yes, we do have 
specific code that pays attention to it.  But I'm less insistent about 
this one than I am of "z=".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2009 21:54:24 -0700 (PDT)

> implementer and a validator might not.  Hence, no interoperability.

In the case of "z=", for example, a verifier electing not to implement 
would simply ignore the tag.

> If the use of a tag by a signer, with non-support by the verifier, will 
> prevent interoperability, then I think it can't be optional.

I've long had a policy that goes past what RFC4871 says.  Our software 
implements in two layers: basic DKIM (libdkim) and then a filter that uses 
that interface (dkim-filter) to conduct verification and then implement 
local policy.

Aware of the security risks of "l=" (which are well documented), upon 
receiving a signature that used "l=", libdkim might tell the filter the 
signature validated, but the filter can also ask the library how much of 
the message was signed (i.e. get the value of "i=") and compare this to 
the total message size; if there was too much additional data, the filter 
is able to consider the signature invalid anyway as a matter of local 
policy.

Given this, I'd say we should list "l=" as a MAY, and advise signers that 
a verifier might not care that you said "l=", be that simply because "l=" 
wasn't implemented at the verifier, or perhaps it was implemented but the 
verifier had a strict policy on its use and your message violated it. 
Thus, we've defined it, but we don't promise it will be universally 
useful.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2009 21:32:41 -0700 (PDT)

On Sat, 9 May 2009, Dave CROCKER wrote:
>      "The simpler a spec is, the easier it is to develop, test and 
> operate, and the easier it is to explain to others. "
>
> Rather than cycling around on a conceptual point, try considering the 
> specific reasons given to deprecate each of the tags and see if there 
> are counter-arguments for why the tag is actually really important.

For the sake of trying to find some compromise, can we do what we did with 
the AUID/SDID debate and indicate which tags an implementation MUST 
support and which ones it MAY support?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 May 2009 22:18:54 -0700

Murray S. Kucherawy wrote:
> Given this, I'd say we should list "l=" as a MAY, and advise signers 
> that a verifier might not care that you said "l=", be that simply 
> because "l=" wasn't implemented at the verifier, or perhaps it was 
> implemented but the verifier had a strict policy on its use and your 
> message violated it. Thus, we've defined it, but we don't promise it 
> will be universally useful.

For l=, a MAY for signers produces a MUST for verifiers.

If a signer bases their signature on use of an l= value, then the signature will 
fail if the verifier does not implement it.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 May 2009 22:23:00 -0700

Murray S. Kucherawy wrote:
>   I'd rather leave an unused 

Murray, this is an absolutely basic bit of philosophy in protocol design.  It 
drives lots of decisions.

Unfortunately, historically, this is exactly the logic that adds useless bloat 
to protocols and causes interoperability problems.

When a feature is not currently used, it tends to be badly implemented, since it 
isn't exercised.  By adding it later, you are ensuring that there is a real need 
and, therefore, real end-to-end testing.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2009 22:51:58 -0700 (PDT)

> For l=, a MAY for signers produces a MUST for verifiers.

Why is that necessarily the case?

> If a signer bases their signature on use of an l= value, then the 
> signature will fail if the verifier does not implement it.

That was kind of my point.  And I think that's OK, since even though my 
verifiers do implement it, local policy in the assessor agent could 
disregard its validation anyway.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 May 2009 09:37:08 +0200

> Why is that necessarily the case?

Right.  l= may simply be ignored and the signature considered invalid if 
the message is different.  On the other hand, have we really spotted 
valid use cases?  I was pondering cooperating DKIM senders and mailing 
lists and the possible use of multipart/alternative, but that seems far 
more complex than useful.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 11 May 2009 08:36:04 -0000

>That means there's at least a little demand for its use.

Any idea what they're doing with it?  Having added some support for
DKIM to majordomo2, I am more convinced than ever that the motivation
for l=, list recipients will filter list mail using the contributor's
signature rather than the list signature, is just wrong.

If I may pile on, let me reiterate Dave's point about q=.  In the
unlikely event that we invent another way to look for key records,
that's the time to design the syntax to specify it.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 May 2009 11:55:55 +0100

> seems unlikely we'd reach any consensus to drop it.

At the moment, this tag plays no part in the protocol (except that it  
needs to be correctly signed). It has caused confusion, which our recent  
errate have sought to dispel. Now there is the opportunity to sit down and  
define some proper rules for its use, if we are so minded (e.g. in mailing  
lists). Essentially, it could be useful for signatures which are NOT by  
the Author Domain.

> situations where it has proved useful?

Signing the body is not essential for the primary purpose of DKIM, which  
is to expose phishers and the like. Malicious modification of a message  
_after_ is has been posted is relatively rare. So writing l=0 gives a way  
to sign the headers only (saving quite a bit of overhead if that is  
useful, plus removing all problems arising from changes of encoding and  
other mungings during transit. Moreover, there are too many agents arounf  
that insist on adding boilerplate to the end of messages (look what the  
mailing list expander for this list does, for example). Putting a proper  
l= value circumvents that problem (which is why it was out there in the  
first place).

-- 
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 Levine <[email-masked]>
Date: 11 May 2009 13:58:04 -0000

>>      l: Body length count ...

>_after_ is has been posted is relatively rare.

Aw, come on.  If the Bank of X were to send out mail with only the
headers signed, how many milliseconds do you think it would take
before bad guys replaced the URLs with fake ones and spammed it out?

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 May 2009 08:09:58 -0700

On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:

> On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins <[email-masked] 
> >
> wrote:
>
>>
>>     l: Body length count
>>

If a signer uses l=0 (or, given MIME games that can
be played, any other l= value) then the only thing you can say
about any validly signed message from that sender is that
the subject line of the message is the same as the subject line
of a message that sender signed. I don't think that's a useful
level of protection for any use case.

It means that I can, for example, take one copy of a service notice
from my bank, leave the headers the same and replace the URLs
in the body of the message to links to my website, then send it
out to a hundred thousand people - and it would be validly signed
by the bank. (The only user-visible content I wouldn't be able to
change is the subject line).

If there is ever any user-visible sign in an MUA that an email was
DKIM signed, or benefits to delivery for email being DKIM signed by
a trusted signer, *and* some trusted signer actually uses l=0, I'll bet
you'll start to see a lot more malicious modification and retransmission
of messages.

> So writing l=0 gives a way
> other mungings during transit.

> Moreover, there are too many agents arounf

That assumes that the important signature in that case is the original
authors, not the mailing lists, and that the mailing list itself isn't  
trusted.
I think the normal model of a mailing list is not a simple mail  
forwarder,
rather an agent that receives and validates mail then sends mail out
to subscribers under the mailing lists signature.

I could conceivably see this being an issue on an acm.org style  
forwarder,
if there were one that modified the content it forwarded, but not a  
normal
mailing list. I don't think that's a iikely use case, though.

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 May 2009 17:29:43 +0200

On 5/11/09 5:09 PM, Steve Atkins wrote:
>> On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins<[email-masked]
>>      
>>>        
>> wrote:
>>
>>      
>>>      l: Body length count
>>>

Sorry- I'm not quite sure what you're saying here.  That an ACM.ORG-like 
forwarding address is likely or that they would tag something to the 
bottom of a message?

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 May 2009 08:47:08 -0700

On May 11, 2009, at 8:29 AM, Eliot Lear wrote:

> Sorry- I'm not quite sure what you're saying here.  That an ACM.ORG- 
> like forwarding address is likely or that they would tag something  
> to the bottom of a message?

I think it unlikely that they would modify the message, while not  
taking any responsibility for the message content.

A simple .forward style forwarder is fine, as it doesn't modify the  
content.

A forwarder that does modify the content in any way will invalidate  
DKIM signatures that do not use l= [1]. Because of that it will need  
to take that into account operationally, probably by signing with it's  
own signature on outbound and maybe validating signatures on inbound  
mail[2].

Whatever it does to handle forwarding of non-l=-using DKIM signed  
email correctly will also that it also forwards l=-using DKIM signed  
mail correctly, meaning l= adds no obvious value there.

Cheers,
   Steve

[1] it'll likely invalidate ones that do use l= too, but that's not  
important here.

[2] One of the more plausible use cases for the Authentication-Results  
header, where the header shows the results of inbound DKIM validation  
and is signed by the forwarders signature on outbound mail.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 May 2009 08:47:02 -0700 (PDT)

On Mon, 11 May 2009, John Levine wrote:
> Any idea what they're doing with it?  Having added some support for DKIM 
> to majordomo2, I am more convinced than ever that the motivation for l=, 
> list recipients will filter list mail using the contributor's signature 
> rather than the list signature, is just wrong.

I'll ask the person who submitted the patches, and also ask if anyone else 
is using them.

> that's the time to design the syntax to specify it.

Yep, I agree.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 May 2009 11:02:31 -0600

> Summary of features to keep

+1 to keeping these.

> Summary of features to consider dropping

+1 to dropping these, though I'm willing to be convinced otherwise if there 
are verifiers actively using them to make policy decisions -- particularly z=.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 May 2009 10:46:10 -0700 (PDT)

On Mon, 11 May 2009, J.D. Falk wrote:
> +1 to dropping these, though I'm willing to be convinced otherwise if 
> there are verifiers actively using them to make policy decisions -- 
> particularly z=.

I can't imagine using "z=" as an input to a policy decision.  I've only 
found it useful when debugging at specific sites.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 May 2009 10:48:55 -0700

On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:

>>    i: Additional information about the identity of the user or  
>> agent for which this message was signed
>>
>> This one is more controversial. It adds an awful lot of complexity  
>> and confusion about the semantics of what a signature is and quite  
>> a few people (myself included) would prefer it went away. But there  
>> are some potential uses for it, and some are already invested in  
>> it, so it seems unlikely we'd reach any consensus to drop it.
>
> At the moment, this tag plays no part in the protocol (except that  
> it needs to be correctly signed). It has caused confusion, which our  
> recent errata have sought to dispel. Now there is the opportunity to  
> sit down and define some proper rules for its use, if we are so  
> minded (e.g. in mailing lists). Essentially, it could be useful for  
> signatures which are NOT by the Author Domain.

Disagree. This tag plays an important role in the protocol!  This tag  
permits differentiation of intra-domain sources to mitigate replay  
abuse, and is supported by RFC 5451 to aid MUA annotations.  Any  
attempt to use the i= value for email-addresses where the signing  
domain is not authoritative will create incompatibilities.

Different domains can authorize a DKIM signing domain within a single  
transaction.  A convention using a specific dedicated sub-domain, such  
as "_authorized",  within the i= value could even indicate an  
expectation of the signing domain being authorized by the From email- 
address domain.  Perhaps this could be done with base-64 encoded hash  
labels placed within the From email-address domain.  This would be a  
fairly low overhead (about that of CNAMES), and allow any number of  
domains to be authorized.

For example:

<hash of example.com>._dkim_authorized.other-example-domain.com TXT  
"example.com"

From: [email-masked]
DKIM-Signature: i=[email-masked]; d=example.com

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 May 2009 11:17:39 -0700

On May 9, 2009, at 11:06 PM, Eliot Lear wrote:

>>> with some editorial changes I guess. I've not seen anyone suggest  
>>> that we add features or remove a raft of features or make other  
>>> substantial changes.
>>>
> I like deprecating useless stuff, but before we do that I would like  
> to see broader implementation, and again, specifically in mailing  
> list managers, before we decide what is useless.

Agreed.  It appears merging errata now means explaining once again why  
features were included and why their possible use should be supported,  
even if only to generate clueful error messages.  It may takes years  
before issues being addressed by some feature becomes apparent.  This  
may occur only after greater adoption and MUA integration where  
reliance and annotations make their impact perhaps several years from  
now.

For example, providers may insist upon adding a disclosure  
notifications at the end of emails.  The l=value, when used  
appropriately and is properly supported, could ensure a message  
remains in an state that will not prohibit non-repudiation, by being  
explicit about the body length.  This feature may also allow providers  
a means to escape the hashing large attachments, for example.

DKIM is too new.  Anything looks complex until people get used to it.   
I also fear there are those with conflicted interests which might wish  
to emasculate DKIM to better enable competing strategies.  DKIM needs  
to be better protected from change based upon one's perception of  
complexity.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 May 2009 16:16:58 -0400

> to be better protected from change based upon one's perception of  

Well said.

-- 
Sincerely

Hector Santos

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 May 2009 09:55:53 -0700

> change is the subject line).

This sounds like a plausible and serious scenario.  Even with l>0, it suggests a 
line of attack -- by adding malicious text that appears to be part of the bank 
notice.

What is the counter-argument, in favor of retaining l= ?

Is there any evidence it is being used?  Is there any evidence it is treated 
usefully by receivers?

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 May 2009 12:10:40 -0700

On May 20, 2009, at 9:55 AM, Dave CROCKER wrote:
>
> Steve Atkins wrote:
>> If a signer uses l=0 (or, given MIME games that can be played, any  
>> other l= value) then the only thing you can say about any validly  
>> signed message from that sender is that the subject line of the  
>> message is the same as the subject line of a message that sender  
>> signed. I don't think that's a useful level of protection for any  
>> use case.
>>
>> from my bank, leave the headers the same and replace the URLs in  
>> the body of the message to links to my website, then send it out to  
>> a hundred thousand people - and it would be validly signed by the  
>> bank. (The only user-visible content I wouldn't be able to change  
>> is the subject line).
>
> This sounds like a plausible and serious scenario.  Even with l>0,  
> it suggests a line of attack -- by adding malicious text that  
> appears to be part of the bank notice.
>

IIRC, this concern has been discussed at length.  Why rehash the l=  
feature so soon?

> Is there any evidence it is being used?  Is there any evidence it is  
> treated usefully by receivers?

Again, it seems too soon to tell.

IMPOV, malware scanning email, once considered essential,  must not be  
relied upon to detect threats. :^(

Any application attachment should generally contain source  
authentication signatures.  As this happens, DKIM protections become  
redundant for such application attachments.  This redundancy might  
become significant for large attachments, especially when DKIM adopts  
more resource intensive hashing algorithms.  There are new products  
and services emerging, along with a growing use of various content  
protection schemes.  The next few years will likely witness an  
industry evolve as it responds to what is becoming a serious security  
crisis.

People tend to treat email as a means of sharing files.  These files  
are then published and redistributed using various means.  This mode  
of sharing is not ideal, but having application information exchanged  
in self-authenticating containers would make security much easier to  
manage.

Since email must deal with large amounts of spam and abuse, it would  
be good to have provisions in DKIM that allow secured attachments to  
be excluded from the DKIM hash algorithm without causing the entire  
message to be considered unsigned.

Also, it is common to find notices or ads appended to messages.   
Explicit length indications as to what is signed provides a means to  
better determine what should and should not be annotated, without the  
entire message being considered unsigned.

It seems prudent to wait.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 May 2009 13:32:53 -0700

On May 20, 2009, at 12:10 PM, Douglas Otis wrote:

> message to be considered unsigned

Why would you want to sign email as something you vouched for,
while still enabling anyone to replace the content of the email
with something else without invalidating that signature?

A low-end, $30 x86 CPU can hash well over 100 megabytes of SHA256
a second, more than enough to saturate an OC-12, so the cost of
signing cannot be the reason you want to do so.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 14:17:39 -0700

> with something else without invalidating that signature?

You can't replace it; you can only append to it.

		Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 May 2009 14:29:32 -0700

> with something else without invalidating that signature?

As I recall, the primary argument in favor of l= was survival after being 
relayed through a Mediator like a mailing list, many of which add a footer to a 
message.  (Proof of concept:  This message is an example.)

A different way of looking at this goal is that it is an attempt to sign parts 
of a message body, rather than all of it, much as one might do with s/mime or 
openpgp.

Hence, l= participates in the general desire to have a DKIM signature survive 
the transfer path.  Note that having a signature cover only some of the header 
fields is another example of this.

I think the counter-argument to this goal, with respect to the body, is that 
header fields other than primary addressing fields and the Subject field are not 
particularly high-leverage targets for deception, the way the body is.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 May 2009 14:35:03 -0700

> You can't replace it; you can only append to it.

That's likely wrong, depending on the details of the l= usage.

Firstly, one expressed use case for l= is "l=0" - in other words, don't
sign any of the body. In that case I can put any body content in there
I like, and it'll still be validly signed.

Another use case is to use l= to sign a text part of an email, but not
to sign an attachment. In that case I can obviously replace the  
attachment
with my own content, but depending on the details of the email structure
I may well be able to replace the text section as rendered to the user
as well.

Another use case is to set l= to the entire length of the email as sent.
This case is a little less nonsensical than the others (though the  
supposed
benefit it offers is not clear). I can still append raw content.  
Depending on
the structure of the email I may well be able to have that appended  
content
displayed in place of the original content. This is harder to exploit  
such that
you can entirely replace the original content than the other cases,  
but given
multipart mime and html there's no way I'd say it's impossible.

(And, if we're talking phishing attacks, which is one of the supposed  
risks,
then I can put a very effective phishing attack in just the footer of  
a message
anyway - the place people expect to find "Contact Us" or "Log in to your
account" or "Secure your access" links).

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 14:53:05 -0700

> That's likely wrong, depending on the details of the l= usage.

   No I'm not.

> I like, and it'll still be validly signed.

   That's still appending.

> to sign an attachment. 

   That's still appending.

> Another use case is to set l= to the entire length of the email as sent.

   That's still appending.

   DKIM only talks about taking responsibility, and only for the parts that
   are signed. How an evaluator deals with the unsigned parts of a message
   is outside of the scope of DKIM.

 > (though the supposed benefit it offers is not clear)

   You forgot "to me".

  		Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 May 2009 14:42:45 -0700 (PDT)

On Wed, 20 May 2009, Steve Atkins wrote:
> attachment with my own content, but depending on the details of the 
> email structure I may well be able to replace the text section as 
> rendered to the user as well.

Indeed, Outlook will opt to render an HTML part over a text part whenever 
given the choice.  Thus, if you sign only the text/plain portion of a 
message and an attacker appends a text/html part, the unsigned HTML 
version will be rendered even if completely different from the text/plain 
part, and DKIM would give that a thumbs-up.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 May 2009 15:41:53 -0700

>> Another use case is to set l= to the entire length of the email as  

It's only appending if you don't care about the email itself, just the  
protocol.

Remember that we're considering the content of the message as  
displayed to the end user here, not the traffic on the wire. If I can  
control the content of the message as it's displayed to the recipient,  
then the fact that I only have limited control as to the changes I can  
make to the bytes on the wire is pretty much irrelevant.

>  is outside of the scope of DKIM.

But when we're talking about the benefits of something you can't  
constraint your discussion to just the details of the protocol - how  
it will be used, and how it will be attacked, in use are the core of  
what's important, and definitely within the scope of a discussion  
about whether a feature provides a benefit or not.

> > (though the supposed benefit it offers is not clear)

Not really. I don't think the supposed benefit clear to anyone,  
including those who are interested in including the feature. There  
have been a couple of concrete examples suggested, but they mostly  
don't actually make any sense when you dig into the details.

There are a few, exceptional cases where using l= to preserve a DKIM  
signature via a forwarder that would otherwise break it would actually  
work (a sender choosing to use l= to sign the entire length of their  
message sending plain text mail to a mailing list that does not modify  
the body of the message other than appending a footer and does not  
modify the signed headers - no From, Subject, Reply-To changes - for  
instance).

But those few cases are so rare or unlikely as to be pretty much  
theoretical. You can find more likely cases by reducing what you sign  
(don't sign the Subject,
don't sign the From:, don't sign Reply-To: and so on), but once you  
start doing that then you're really opening yourself up to replay  
attacks. (Even if you don't care about replay attacks yourself, they  
mean that a DKIM signature - or at least one using l= - becomes pretty  
much meaningless to the

None of the mailing lists I'm currently subscribed to could take  
advantage of l= to preserve a DKIM signature in general (the only ones  
that append a footer also rewrite the subject to add a mailing list  
tag or add a Reply-To) - though some of them would support it in the  
case of replies to email from the list. None of the email I see that  
has advertising appended to it has had the advertising appended after  
it has been (or would have been signed).

I've no doubt someone can find a real-world example but unless it's  
reasonably common for l= to be useful- rather than vanishingly rare -  
it doesn't seem enough to count as a significant benefit, let alone  
one that's big enough to counterbalance the security holes it opens.

If there's a use case I've missed, I'm all ears.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 15:43:02 -0700

Murray S. Kucherawy wrote:
> given the choice.  Thus, if you sign only the text/plain portion [...]

Seriously: how signers and receivers use DKIM information is >>>>WAY<<<<
outside of the scope of this working group. To read the hand wringing here
you'd think that spam filter writers are complete idiots. They aren't.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 15:57:06 -0700

Steve Atkins wrote:
> displayed to the end user here, 

   No we're not. That has never been in the scope of the DKIM effort.

> including those who are interested in including the feature. 

   Speak for yourself, please. And the archives for this -- and
   everything else you've brought up -- are your friends.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 May 2009 16:14:05 -0700

>  No we're not. That has never been in the scope of the DKIM effort.

Even if it weren't section 8.1 of the existing RFC, it's pretty  
obvious that a security issue that allows an attacker to create a  
validly signed email with their own content without access to the  
associated private key would be in scope for discussion.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 16:31:09 -0700

> associated private key would be in scope for discussion.

   They cannot alter the signed text. That's all DKIM guarantees. It's
   not in DKIM's scope to tell mail receivers what to do with the
   message, signed text or otherwise. Stupid receivers are free as always
   to do stupid things. Smart receivers are free as always to do smart
   things. As is ever was.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 20 May 2009 16:47:49 -0700

On May 20, 2009, at 4:31 PM, Michael Thomas wrote:

>  They cannot alter the signed text.

They can't alter the signed *bytes*. They *can* alter the signed text.  
That's the crux of the issue.

> That's all DKIM guarantees. It's

Sure. The question is whether we want to have the spec encourage smart  
behavior or encourage stupid behavior.

The existence of l= certainly allows stupid behavior, and probably  
encourages it.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 May 2009 16:54:56 -0700

> That's the crux of the issue.

No they can't. At least not without invalidating the signature.

Crux dismissed.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 May 2009 17:24:29 -0700

On May 20, 2009, at 2:42 PM, Murray S. Kucherawy wrote:

>> Another use case is to use l= to sign a text part of an email, but  
>> not to sign an attachment. In that case I can obviously replace the  
> Indeed, Outlook will opt to render an HTML part over a text part  
> whenever given the choice.  Thus, if you sign only the text/plain  
> portion of a message and an attacker appends a text/html part, the  
> unsigned HTML version will be rendered even if completely different  
> from the text/plain part, and DKIM would give that a thumbs-up.

Outlook gives a thumbs-up to domain MTA authorizations as the source  
regardless of other domains also sending through the MTA.  RFC5451  
intentionally fails to provide MTA identities that could have enabled  
MUAs a means to annotate questionable authorizations.  It remains  
fairly impractical and unsafe to rank domains based upon authorization  
of widely shared MTAs under different entities' control.  Many large  
corporations share outbound MTAs for many reasons.  Bad actors will  
have little trouble defeating the facade of MTA authorization and  
thereby create many victims.  If Outlook does something equally as  
reckless as annotating unsigned content as being signed, that  
illustrates bad MUA design, not a bad protocol.

The DKIM signature is normally unseen.  Those adding annotations must  
be held accountable.  Unlike authorization schemes, at least DKIM  
indicates _exactly_ what portion of message was signed, and  
specifically which domain added the signature.  Those signing messages  
may decide to be explicit about the length of their message.   Doing  
so better ensures notifications and ads that might be added by a  
recipient's provider will not impair annotations of signed message  
portions.

Just as DKIM currently separates the body hash from that of headers, a  
header could include verification hashes for attachments as well.   
This would move performing hashes over large objects to the senders  
and recipients.  Having the l= parameter in place enables this type of  
trade-off.  Large MTAs will be performing may operations of related to  
verifying compliance, or perhaps doing mash-ups.  The burden placed  
upon these systems can be reduced by a practice of creating separate  
authentication containers for attachments. There are competing  
companies introducing these products today.  It seems reasonable to  
expect that soon this feature will find good use.

DKIM is extremely explicit about what is and is not signed.  Receiving  
a message where no message body is annotated as being signed should be  
accompanied by a warning.  DKIM would become fairly inflexible when  
every feature must accommodate only one type of use.  Removing DKIM  
features will not ensure good MUA design.  There are many issues of  
equal concern not mitigated by removal of feature flexibility.  If  
some MUA gets it wrong, there will be other better choices available.

-Doug

---

From: SM <[email-masked]>
Date: Wed, 20 May 2009 17:08:14 -0700

Hi Steve,
>make to the bytes on the wire is pretty much irrelevant.

DKIM is not end to end.  We only have to preserve the validity of the 
DKIM signature up to the DKIM verifier.  "l=" was introduced because 
some mailing lists appends (sometimes it's more than that) a footer 
to the message.  I tested "l=" with Mailman a few years back and the 
DKIM verification was successful even if a footer was added along the 
path between the signer and verifier.

I don't think we should mix the content of the message with "signed" 
body.  If the verifier passes the "unsigned" part without additional 
checks, there will be abuse.

>But when we're talking about the benefits of something you can't

If I recall correctly, the feature was added to fulfill one of the 
requirements.

>modify the signed headers - no From, Subject, Reply-To changes - for

Even if you use the "l=", you can still get end up with a broken 
signature because of the subject tag.  The Reply-To doesn't usually 
break the signature.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 May 2009 20:49:37 -0400

> The existence of l= certainly allows stupid behavior, and probably  

Hence the DKIM policy hypocrisy.  Policy Protocols are not being 
worked out, yet, we have all these questionable subjective policy 
based decisions being made to the DKIM base protocol that really are 
not universal agreements, and like much of the decisions made based on 
rough consensus, DKIM has been crippled and stagnated in many ways.

There are useful ideas for l= and like the cautions we can apply to 
many useful ideas, this is no different.  If a feature or idea 
usefulness or lack of was obvious that would be one thing, but it isn't.

DKIM needs stability so that WIDER ADOPTION of implementators across 
all markets and operations can a) take it seriously to see how it can 
provide a payoff, b) see how it integrated into their frameworks  and 
c) see how policy can be wrapped around it.

-- 
Sincerely

Hector Santos

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 21 May 2009 10:34:38 +0100

> line of attack -- by adding malicious text that appears to be part of  

Only if the bank was stupid enough to sign with l=0 in the first place.  
Clearly people who know they are phishing targets will not have l= tags at  
all.

But the vast majority of email senders are not phishing targets.

> What is the counter-argument, in favor of retaining l= ?

l=0 might be appropriate for Usenet control messages, where the important  
information is entirely in the headers. Even if l=<length of message> were  
used it would help, since currently the commonest cause of Usenet control  
message failures is extra white lines tagged on the end in transit.

l=0 would also be appropriate when other precautions were being taken to  
authenticate the bidy (e.g. Content-MD5, where the Content-MD5 header  
itself was included in the signature).

And l=<actual message length> is always suitable when the end of the  
message is marked clearly in some other way, so that an addition is  
immediately seen as such.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 May 2009 14:40:36 +0200

Steve,

I find your arguments largely unconvincing.

> I like, and it'll still be validly signed.

There are specific applications for such a case, and most of them are, 
in my experience, programmatic, where there is no body, or where the 
body is merely a comment (I've seen both forms commonly used).

> I may well be able to replace the text section as rendered to the user

This depends entirely on MIME multipart/alternative.  Any reasonable 
implementation would drop a message that was signed that offered an 
alternate part beyond the l= length.

> multipart mime and html there's no way I'd say it's impossible.

And another thing to point out is that even absent the signature, why 
would a message not be treated as suspicious if it had to parts of the 
same type (again, speaking of multipart/alternative)?  My own (painful) 
experience is that this is the default for one of the most widely used UAs.

> account" or "Secure your access" links).

The whole point of l= was to say that beyond it you should treat the 
content as suspicious.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 May 2009 14:42:34 +0200

> part, and DKIM would give that a thumbs-up.

The conditions anticipated by l= was the limited case where a mailing 
list would append bits of information, such that the rest of the 
signature could be retained.  As John has pointed out, that is 
challenging because of all of the rewriting that goes on.  So I think we 
need to back up and decide whether it's worth arguing over whether a 
behavior change in the base is something we want to encourage.  I don't 
have an opinion on that at the moment.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 May 2009 07:45:17 -0700

Eliot,

Since DKIM Signature does not make statements about the differential handling of 
content, signed or unsigned, I'm not clear what you base this assertion on.  Can 
you clarify?

As I understand DKIM Signature, there is are validly signed messages (with their 
identifiers) and there are all other messages, and that binary distinction is 
the limit of DKIM semantics.  You appear to be going beyond the specification.

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 May 2009 17:23:50 +0200

On 5/21/09 4:45 PM, Dave CROCKER wrote:
> Since DKIM Signature does not make statements about the differential 
> handling of content, signed or unsigned, I'm not clear what you base 
> this assertion on.  Can you clarify?
>
> As I understand DKIM Signature, there is are validly signed messages 
> (with their identifiers) and there are all other messages, and that 
> binary distinction is the limit of DKIM semantics.  You appear to be 
> going beyond the specification.

I think the point is that you can't make assertions of responsibility 
for the information beyond l=.  That was always the implication, right?  
So now you're a mail firewall and you see lots of URLs tagged at the 
end, with nobody asserting responsibility.  That's an indicator that 
there is a problem.  What one does with that problem is well beyond the 
scope of DKIM, but one could easily see several different courses of action:

1.  stripping the URLs
2.  quarantining the entire message
3.  posting a warning IN the message

But again, this is all really academic, depending on the point of 
actually USING l=.  How can it LEGITIMATELY be used.  We can find ways 
to deal with miscreants using l=, but it may not be worth it if we can't 
find legitimate uses...

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 May 2009 08:45:48 -0700

Eliot Lear wrote:
> for the information beyond l=.  

Eliot,

But with respect to "assertions" about a message, DKIM only has valid-vs-unsigned.

There is no concept of "responsibility for information behond l=".

>  That was always the implication, right?  

It is no where in the specification and I believe it never was.

> scope of DKIM, but one could easily see several different courses of action:

Now you inventing behaviors that go far beyond the specification.

If such behaviors are necessary to make l= meaningful and useful -- and your 
line of frankly reasonable thinking does seem to imply this, though I doubt it 
was your intention -- then the specification for this bit of mechanism is 
seriously deficient.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 May 2009 17:59:21 +0200

> There is no concept of "responsibility for information behond l=".

Sure there is.  It is simply "unsigned" beyond the value of l=.

> It is no where in the specification and I believe it never was.

I believe this was explicitly stated elsewhere, like on this list.

>> there is a problem.  What one does with that problem is well beyond 
>> the scope of DKIM, but one could easily see several different courses 
>> of action:
>
>

Well, that is what I wrote (I concede I don't know the difference 
between well beyond an far beyond ;-)

>
> If such behaviors are necessary to make l= meaningful and useful -- 
> and your line of frankly reasonable thinking does seem to imply this, 
> though I doubt it was your intention -- then the specification for 
> this bit of mechanism is seriously deficient.

Perhaps, but why do you think so?

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 May 2009 09:08:12 -0700

> Sure there is.  It is simply "unsigned" beyond the value of l=.

You appear to be confusing the difference between the internals of how DKIM 
determines whether there is a valid signature, from fine-grained (output) 
semantics about the message.  DKIM  merely says that a valid signature is 
present or it isn't.  It makes no statement about differential coverage of the 
message.

Separate from text that defines the verification algorithm, can you point to 
text in the Signature specification that refers to differential semantics or 
differential output from the verifier?

> I believe this was explicitly stated elsewhere, like on this list.

But that's not in the spec.

> between well beyond an far beyond ;-)

Maybe lateral vs. vertical?  a well can be deep and far can be to the horizon...?

> Perhaps, but why do you think so?

You've been relying on interpretations that aren't in the specification.  If you 
  restrict discussion to only using semantics from the specification (with the 
Update) then I'm not understanding what value proposition applies.

And by the way, my original question was about who is using the feature and 
finding it valuable.  Not about theoretical scenarios, but experience based on 
two years of possible use.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 May 2009 12:13:19 -0400

> But with respect to "assertions" about a message, DKIM only has valid-vs-unsigned.

Unfortunately, that was a policy decision and it is conflictive with 
the realistic technical values of a malfunctioning operation. There 
are three technical states software provides:

     signed and valid
     signed and invalid
     unsigned

To eliminate one is a policy decision.

-- 
Sincerely

Hector Santos

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 May 2009 09:18:41 -0700

> two years of possible use.

The archives are your friends. This has been stated innumerable times
with real-life statistics.

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 May 2009 19:43:35 +0200

> But that's not in the spec.

That's because the topic of what a verifier does with a message was 
probably viewed as out of scope.  But that doesn't imply, as you agreed, 
that the application of certain rules based on garbage at the end should 
not occur.

>>> and your line of frankly reasonable thinking does seem to imply 
>>> this, though I doubt it was your intention -- then the specification 
>>> for this bit of mechanism is seriously deficient.
>>
> You've been relying on interpretations that aren't in the 
> specification.  If you  restrict discussion to only using semantics 
> from the specification (with the Update) then I'm not understanding 
> what value proposition applies.

I think you are confusing uses for interpretations.  Of course 
information beyond the l= value should be treated with some suspicion.  
Otherwise all that stuff that Steve mentioned can happen in some cases.

> And by the way, my original question was about who is using the 
> feature and finding it valuable.  Not about theoretical scenarios, but 
> experience based on two years of possible use.

And see my other message.  I also question the value of l=.  All I was 
trying to say here was that the risks are well documented and easily 
mitigated.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 May 2009 12:06:58 -0700

On May 21, 2009, at 10:43 AM, Eliot Lear wrote:
>
> And see my other message.  I also question the value of l=.  All I  
> was trying to say here was that the risks are well documented and  
> easily mitigated.

Agreed.

There are many areas beyond the scope of DKIM that might be of similar  
concern.  When an MUA only displays friendly-names that are signed  
with a g= restricted keys, this would represent another area of concern.

DKIM results are unlikely to always provide simple answers nor will it  
ensure simple annotations will be sufficient.  Sorry, but DKIM is  
attempting to retrofit security into highly diverse environments and  
uses.  There are no simple solutions.

While daily observing millions of compromised systems operating from  
centralized control, the concept of being able to iteratively append  
junk to the end of a phish body until it collides with a signed body  
hash appears to make defeating the hash easier.  Calculations of  
difficulty for doing this may need to consider today's environment.   
The l= parameter should make this more difficult.  This has been  
raised because a few have also suggested expiry is also not needed.   
Having these arrows at the ready in the quiver allows a means to  
respond with far less disruption than would result without these  
features being available.

Are MUA vendors unable to handle the information present within

a) the DKIM signature?

b) RFC 5451 results?

If simple answers are required, use S/MIME or OpenPGP.  DKIM provides  
the flexibility to handle a diversity of uses and environments.  Such  
flexibility demands greater care when MUAs attempt to apply  
annotations.  And yes, these annotations may be required to indicate,  
strip, or split unsigned message portions.  It is too soon to tell  
what features will be needed and how best they can be used.  What is  
clear, there are no simple answers for whether an entire message is to  
be annotated or not.  When a message is being signed by g= restricted  
keys, even the friendly name should be excluded.

-Doug

---

From: <[email-masked]>
Date: Thu, 21 May 2009 11:16:25 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Thursday, May 21, 2009 10:45 AM
To: Eliot Lear
Cc: DKIM WG
Subject: Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

Eliot,

d/

--

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 21 May 2009 22:40:53 -0000

>body is merely a comment (I've seen both forms commonly used).

I don't get it.  Yes, if you don't care about the body of a message,
using l=0 is mostly (not entirely) harmless, but I don't see that it
solves any problem.  What's the advantage of using l=0 versus signing
the message the usual way?  The speed difference is imperceptible.
Are these messages unusually likely to go via a path that smashes the
body and would break a regular signature?

Also, the reason it's only mostly harmless is that it's still subject
to replay attacks if a bad guy gets such a message, pastes on a spammy
body, and then resends it to a million random people, presumably
thereby destroying whatever reputation the signer had.

>The whole point of l= was to say that beyond it you should treat the 

My recollection of the debate about l= is that there were about as
many theories about the point of l= as there were people promoting it.
The main theory I remember was about hypothetical mailing lists that
were too incompetent to filter incoming spam so the list recipients
would do it based on the signatures of messages that passed through
the list.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 May 2009 07:30:45 +0200

> body and would break a regular signature?

I stated the case, but I think you're right, John.  Why bother is indeed 
a good question.  My only answer would be a minor performance gain if 
one were either processing or generating a whole lot of them.  And it's 
very minor.

> thereby destroying whatever reputation the signer had.

Well, right, but the mitigation for that is the code that does the 
verifying.
> would do it based on the signatures of messages that passed through

Except we now know that one major piece of list software can preserve 
the signature, depending on whether subject is signed / preserved.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 May 2009 02:23:21 -0700

On May 21, 2009, at 10:30 PM, Eliot Lear wrote:

>> many theories about the point of l= as there were people promoting  
>> it.  The main theory I remember was about hypothetical mailing  
>> lists that were too incompetent to filter incoming spam so the list  
>> recipients would do it based on the signatures of messages that  
>> passed through the list.
>
> Except we now know that one major piece of list software can  
> preserve the signature, depending on whether subject is signed /  
> preserved.

While mailing lists are common, it seems doubtful mailing lists will  
be where the l= feature adds much value.  It is fairly common to find  
notices and ads added to messages.  Having the length of the message  
body explicitly defined allows signatures to be checked and added  
content identified without tracking every iterative hash value.

Unlike OpenPGP or S/Mime, the message does not contain a structure  
that might be visible to recipients, but this creates some risk.  Some  
providers might even wish to prevent MUAs a means to verify DKIM  
signatures and thereby remove a means to ascertain exactly what  
portion of the message had been signed, as might be revealed by the l=  
parameter.   When a provider does not offer DKIM signature checking as  
part of their service, adding the l= feature ensures DKIM signatures  
in general remain more reliable.  A declared body length ensures the  
signature remains robust and more able to endure varied use.  A  
partially signed set of the body parts, other than attachments,  
represent a reasonable basis upon which to reject a message as being  
deceptive.  Perhaps an extension to DKIM might even include a signed  
header containing attachment hashes.

One other aspect to keep in mind involves a growing threat caused by  
bot-nets.  Hashes are quickly defeated with rainbow tables.  Not  
having a body length asserted by a DKIM signature header allows the  
generation of hash lists by simply extending a phish body and  
recording results at each length extension.  Millions of systems  
controlled by bad actors can generate partial rainbow tables and be  
queried against intercepted message signature hashes to improve the  
odds of generating convincing spoofs.  By having DKIM signatures  
explicitly declare body length, this then requires significantly  
greater resources to build rainbow tables.  With storage and bot-net  
growth, estimates of the time to defeat hashes may need further  
review.  Causing the generation of rainbow tables to be more resource  
intensive provides another possible benefit of the l= feature.

The current impetus for recent changes to DKIM seem aimed at  
increasing dependence upon the providers performing DKIM signature  
checks rather than allowing MUAs a means to retain this ability when  
needed.  This strategy may even make DKIM appear too unreliable within  
current email infrastructure for conducting commerce.  These changes  
seem unlikely to improve DKIM, nor should the ultimate goal be to only  
allow a DKIM state of Signed/Not Signed.  This takes DKIM down a path  
likely to cause complaints and to generate a greater uncertainty which  
will lead to more victims.

Signed/Not Signed does not represent a result that can be made robust,  
nor made to encompass DKIM's modes of use.  Don't expect DKIM to adopt  
the limitations of authorization strategies as a desired goal.  DKIM  
may not have been signed by the Author Domain, which requires more  
than just a lock-symbol.  In addition, the body of the DKIM message  
may have been appended to or prefixed.  A body length allows a quick  
means to determine which.

How are the suggested "simplifications" to DKIM beneficial when they  
increase the odds of recipients finding legitimate signatures marked  
invalid, or when they make it more difficult for signers and recipient  
to mitigate replay abuse?  Leave DKIM as is and allow time to shape a  
best practices document.  Don't underestimate what a MUA is able to  
convey.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: Fri, 22 May 2009 12:01:00 +0100 (BST)

> Except we now know that one major piece of list software can preserve the 
> signature, depending on whether subject is signed / preserved.

I don't think anyone denies that there are some cases when a signature 
will survive some mailing lists, although the list software I've seen is 
all moving in the other direction -- mj2 will remove and flatten MIME 
parts and Yahoo groups rewrites HTML to add footers, for example.

The question that I've never seen addressed is why bother?  Why would you 
want to filter list mail based on the contributor's signature rather than 
the list's signature?  If a list were having trouble with spam leaking 
through, would you expect the list manager to adjust the config to leak 
more perfectly, or fix the leak?  Over the past two decades mailing lists 
have developed use all sorts of techniques to manage what gets onto the 
list and to keep out unwanted mail, and I've never seen a plausible 
explanation of why anyone would expect that to reverse so completely that 
list recipients would need to do per-message spam filtering.

R's,
John

PS: We do bozo filtering of list mail, but that's easy -- you already know 
if the mail is from the list, so if the From: header says you know who, 
you ditch it.  That's two lines of procmail.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 May 2009 13:20:02 +0200

One of the reasons l= came to be was that we wanted to have as many 
valid signatures out there as quickly as possible, so as to provide a 
reasonable alternative basis for reputation.  There was the presumption 
that the mailing list software would lag, and it has.  Now we know that 
one MAJOR piece of mailing list software can be made to behave, and we 
know how to accommodate it if it doesn't.  But in order to preserve the 
signature, everyone would essentially have to start using l=.  I think 
that is the real question on the table, as to whether that is 
advisable.  There are legitimate reasons to say that it is, and other 
reasons to say that it is not.

Eliot

---

From: "John R. Levine" <[email-masked]>
Date: Fri, 22 May 2009 13:21:16 +0100 (BST)

> One of the reasons l= came to be was that we wanted to have as many valid 
> signatures out there as quickly as possible, so as to provide a reasonable 
> alternative basis for reputation.  There was the presumption that the mailing 
> list software would lag, and it has.  Now we know that one MAJOR piece of 
> mailing list software can be made to behave, and we know how to accommodate 
> it if it doesn't.  But in order to preserve the signature, everyone would 
> essentially have to start using l=.

I still don't get it.  For one thing, the real MAJOR list software on the 
net is Yahoo Groups and Google Groups, each of which I would expect 
handles more discussion list mail than everything else combined, and 
neither of which will ever preserve a signature.

But more to the point, if the goal is to maximize the amount of signed 
mail, the obvious change to make to list software is to make it sign its 
outgoing mail.  That makes 100% of the mail from its lists signed.  Why 
would you waste time with complicated kludges that under the most 
optimistic assumptions would only get a small fraction of the mail signed?

By the way, both Yahoo Groups and Google Groups put on a nice fresh DKIM 
signature of their own, so 100% of their mail is signed today.  Yahoo 
strips off incoming signatures, Google doesn't.  Google adds an 
Authentication-Results: header so if you care and you trust them you can 
see whether they thought the incoming signature was good.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 22 May 2009 14:38:23 +0100

> present or it isn't.  It makes no statement about differential coverage  

Rubbish!

If the verifier reports there is no valid signature (or the signature that  
is present is broken), then all bets are off. But if it reports that a  
valid signature exists, then a perfectly reasonable question, to which the  
verifier should be prepared to answer, is "Fine, so exactly what is it  
that was signed?". And since DKIM defines very clearly what is covered by  
the signature (a list of headers, plus part or the whole of the body),  
that is clearly useful information which DKIM has conveyed and attested.

Sure, the Spec does not say that is useful information, but why should it?  
It is Blatantly Obvious!

Surely you do not suppose that a signature which covers only the From  
header (and that is a perfectly valis signature according to the document)  
is to be accepted as equally valuable to a signature that covers  
everything.

---

From: John Levine <[email-masked]>
Date: 23 May 2009 00:31:18 -0000

>header (and that is a perfectly valis signature according to the
>document) is to be accepted as equally valuable to a signature that
>covers everything.

Probably not, but that's because a dimwit who puts on cruddy
signatures is unlikely to earn a very good reputation.  I really
REALLY do not plan to waste any time inventing heuristics to evaluate
the "quality" of a DKIM signature and I doubt anyone else does,
either.  If you want people to accept your mail, be sure to sign only
good mail, and be sure to sign it in a way that bad guys can't fake.

R's,
John

>It is Blatantly Obvious!

Some things that are Blatantly Obvious are also Just Plain Wrong.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Doug Otis <[email-masked]>
Date: Fri, 22 May 2009 18:06:42 -0700

On May 22, 2009, at 5:31 PM, John Levine wrote:

>> Surely you do not suppose that a signature which covers only the  
>> From header (and that is a perfectly valis signature according to  
>> the document) is to be accepted as equally valuable to a signature  
>> that covers everything.
>
> REALLY do not plan to waste any time inventing heuristics to  
> evaluate the "quality" of a DKIM signature and I doubt anyone else  
> does, either.  If you want people to accept your mail, be sure to  
> sign only good mail, and be sure to sign it in a way that bad guys  
> can't fake.

John,

I would agree signatures currently should cover the message body, but  
this might also include the message body length.  A properly  
structured message should not be prone to attack without the attack  
being rather obvious.  When the body of the message has an open-ended  
length, the number of attempts to produce a collision might be within  
what now seems like a small number of attempts.  With millions of  
computers under centralized control, the time required to defeat an  
open-ended DKIM body hash with a reasonable set of signatures might be  
fairly brief.  For most of these systems, users might not even be  
aware of the role their computer play in the attack.  Anyone that  
signs a fairly generic message, where users could think they are being  
cc'd with comments added in the phish, might prove fairly effective at  
creating victims.

The ability to keep the message format from being messed up by what is  
likely to become a deluge of provider ads would also be a benefit.   
After all, this was one of the driving benefits being sought when  
developing DKIM.  It seems that DKIM combined with RFC 5451 and the  
loss of the l= parameter, this benefit is likely lost as well.  That  
would be a shame.  It would also be a shame to have people still  
wondering who sent which part of a DKIM signed message.

-Doug

---

From: John Levine <[email-masked]>
Date: Sat, 23 May 2009 02:40:44 -0400 (EDT)

> When the body of the message has an open-ended length, the number of 
> attempts to produce a collision might be within what now seems like a 
> small number of attempts.

If SHA256 is that weak, we have worse problems than spoofed DKIM messages. 
Fortunately, nobody I know in the crypto community thinks that it is.

R's,
John