Subject: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

From: DKIM Chair <[email-masked]>
Date: Tue, 10 Mar 2009 10:21:43 -0500

This thread has been split from Dave's long note.

Here's what I want to try, in order to convert the "majority vote" into what 
Stephen and I would be happy to call "rough consensus".  I have not discussed 
this yet with Stephen, in the interest of getting it out here more quickly, so he 
may feel free to object to this and whack me over the head (as Dave has already 
done).

As I said in my note summarizing where we are, the working group vote between the 
a/b/c/d choices has taken the simpler errata changes out of the mix and given us 
draft-ietf-dkim-rfc4871-errata as the path forward.  There were, though, enough 
votes against it for the chairs to consider it "significant", so:

To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we 
will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
written?  If not, will you post specific changes, in OLD/NEW format, that would 
make it acceptable to you?  Acceptable changes must keep the sense of the 
draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://internetmessagingtechnology.org/

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Mar 2009 17:20:44 -0400

> I can do that, but it will probably take a few days.  But for
> clarification, is the new terminology cast in stone?  I have a
> particular problem with the term "User Agent Identifier (UAID)" because
> it doesn't necessarily represent a user agent -- it could, for example,
> represent a mailing list manager.  I greatly prefer the term "signing
> identifier" (which replaces signing identity) because it covers the
> range of use cases more completely.

I'd say it's a fair proposal, and we'll see where it goes.
What I meant was that, for example, it won't work to propose text
changes that roll back the terminology changes altogether.  Or
something like that.  A proposed change with a reason behind it gives
everyone something to work with and to decide, one way or t'other.

Barry

---

From: Jim Fenton <[email-masked]>
Date: Tue, 10 Mar 2009 14:15:03 -0700

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Mar 2009 16:55:50 -0700

Jim Fenton wrote:
> I have a particular problem with the term "User Agent Identifier (UAID)" 
> because it doesn't necessarily represent a user agent -- it could, for 
> example, represent a mailing list manager.  I greatly prefer the term 
> "signing identifier" (which replaces signing identity) because it covers the

One of the tricks in choosing labels is to make sure they each have useful 
meaning, but also that they are different enough to avoid confusion.  Labels are 
intended to have mnemonic benefit.

The two labels in the current Errata draft are defined as:

> Signing Domain Identifier (SDID)
...
> the identity claiming responsibility for the introduction of a message into 
> the mail stream.

and

> User Agent Identifier (UAID)
...
> the user or agent on behalf of whom the SDID has taken responsibility.

Note that the latter definition is taken from the existing RFC4871 text:

> Identity of the user or agent (e.g., a mailing list manager) on behalf of
> which this message is signed

So the UAID term reflects the exact language of RFC 4871 that defines the 
identifier:  user or agent.

If the term is changed to "signing identifier" it will be semantically wrong and 
mnemonically confusing.  Wrong because it's not the domain doing the signing, 
per the definition of SDID, and confusing because the term is almost identical 
to SDID.

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, 11 Mar 2009 14:16:24 +0100

Dave, all,

I think the problem isn't so much that you aren't being precise with 
UAID, but rather two fold:

1.  UA has an existing connotation that people will grab onto.  This in 
itself is mnemonically confusing.
2.  If you're going to add acronyms, let them be ones that either can be 
easily pronounced without having to spell them out.  I won't be in SF, 
but I'll be listening for just how people handle this one ;-)

Still I'm reticent to suggest a change and have a never-ending semantics 
discussion (see q. 2 below about urgency).   Here's what I'd like NOT to 
have happen.  I'd like not to have one term defined in -ter and then 
another term defined in -bis.  It's okay (and IMHO advisable) to drop 
terms, but let's not change them.

As to the chair's request, FWIW I *have* given Dave suggested changes, 
and I believe he has accepted some of them.  I must admit some confusion 
about the process at this point.  It seems that there is an outstanding 
request of Pasi about whether this draft can proceed.  Here are my 
questions:

1.  If it does proceed, what happens with rfc4871bis?  I would expect we 
get to have this whole discussion over again because new avenues open 
themselves up when we are talking about a revision to the standard, like 
deprecating i=, adding r=, and perhaps even eliminating the concept of UAID.

2 .  If it doesn't proceed, Dave has expressed urgency about having an 
erratum published.  I'd like to know if that is still the case, and what 
people believe the right approach to be.

3.  John has offered to rev. ADSP to handle r= instead of i=.  I wonder 
what other people think about that.

Eliot

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 15:24:10 +0100

Eliot Lear wrote:

> As to the chair's request, FWIW I *have* given Dave suggested
> changes, and I believe he has accepted some of them.  I must admit
> some confusion about the process at this point.  It seems that there
> is an outstanding request of Pasi about whether this draft can
> proceed.  Here are my questions:

Since "whether this draft can proceed" could be interpreted in
multiple ways, let me clarify slightly: assuming we have rough WG
consensus about the content, this definitely can proceed, using the
same process we normally use for drafts (IETF Last Call, IESG
Evaluation, RFC Editor queue, and finally RFC NNNN).

> 1.  If it does proceed, what happens with rfc4871bis?  I would
> expect we get to have this whole discussion over again because new
> avenues open themselves up when we are talking about a revision to
> the standard, like deprecating i=, adding r=, and perhaps even
> eliminating the concept of UAID.

This depends on how the charter scopes the work item.

For example, IPSECME is currently working on IKEv2bis (4306bis),
which is quite tightly scoped in the charter:

  "A revision to IKEv2 (RFC 4306) that incorporates the clarifications
  from RFC 4718, and otherwise improves the quality of the
  specification, taking into account implementation and
  interoperability experience. In some cases, the revision may include
  small technical corrections; however, impact on existing
  implementations must be considered. Major changes and adding new
  features is beyond the scope of this work item. The starting point
  for this work is draft-hoffman-ikev2bis."

So, the "bis" draft has absolutely no new features (IPSECME WG is also
working on new features, but they're in separate documents), and no
technical changes that don't count as "small technical corrections"
(which BTW in many cases means just resolving internal inconsistencies
-- one part of the RFC conflicts with some other part, and both can't
be right -- one way or the other).

At other times, it could be better to have a more open charter
(allowing the WG to redesign the protocol if they so decide), but 
for 4871bis, I'd probably recommend something closer to the IPSECME
approach (new features go to separate documents, and no big changes 
in 4871bis either).

If we want to emphasize completing 4871bis quickly, the extreme
scoping would be "draft-ietf-dkim-rfc4871-errata-NN plus the errata
currently submitted to RFC Editor, no other changes". Another
possibility would be this plus "...and remove all features/options 
that don't have at least two independent and interoperable
implementations" (so it could be updated to Draft Standard).

Best regards,
Pasi

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 08:50:08 -0700

> itself is mnemonically confusing.

It's not confusing if the meaning is related.  The term "user or agent" is the 
actual semantics of this value.  I read that as equivalent to "user agent".

The basic UA/MTA model is based on the concept of delegation.  Since DKIM was 
created to delegate the task of claiming responsibility (from the author to the 
entity doing the signing), I see it as a) consistent with the underlying 
constructs of Internet mail and b) warranting terminology for the "user or 
agent" component being similar.

> easily pronounced without having to spell them out.  

Like "TCP" and "SNMP" and "BGP"?

I prefer nicely pronounceable acronyms, too, but the absence of that pleasant 
feature doesn't create a veto.

If you have a more pleasant acronym to suggest -- one that maintains appropriate 
semantics -- by all means do so.  Those of us who developed the SDID/UAID 
acronyms also were not happy with the aesthetics of the choice, but this was the 
best we could come up with.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 08:54:35 -0700

Folks,

Question to the working group...

DKIM Chair wrote:
> make it acceptable to you?  

Unless I've missed or misread other postings, the only item lodged, so far, has 
been Jim Fenton's suggest that the UAID acronym be replaced, and discussion 
about that is proceeding.

Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Mar 2009 17:14:11 +0100

On 3/11/09 4:50 PM, Dave CROCKER wrote:
>
>
> Eliot Lear wrote:
>> 1.  UA has an existing connotation that people will grab onto.  This 
>> in itself is mnemonically confusing.
>
> It's not confusing if the meaning is related.  The term "user or 
> agent" is the actual semantics of this value.  I read that as 
> equivalent to "user agent".

It's not.  A user agent is an application that acts on behalf of the 
user but is not the user.  And it is used to refer the MUA.
>
> The basic UA/MTA model is based on the concept of delegation.  Since 
> DKIM was created to delegate the task of claiming responsibility (from 
> the author to the entity doing the signing), I see it as a) consistent 
> with the underlying constructs of Internet mail and b) warranting 
> terminology for the "user or agent" component being similar.
>
>
>> 2.  If you're going to add acronyms, let them be ones that either can 
>> be easily pronounced without having to spell them out. 
>
> I prefer nicely pronounceable acronyms, too, but the absence of that 
> pleasant feature doesn't create a veto.

And I'm not proposing a veto, Dave.  I'm saying, 'yuck, but okay' 
precisely because I really don't think anyone sees as desirable semantic 
email ping pong to come up with a better term.  Also I realized I didn't 
give the other half of that "either" above which is "use short 2 or 3 
letter acronyms".  My personal preference for best acronym used by the 
IETF is still IPoLPDN.  I leave it as an exercise to the reader or the 
reader's memory to understand how that was pronounced.

>
> If you have a more pleasant acronym to suggest -- one that maintains 
> appropriate semantics -- by all means do so.  Those of us who 
> developed the SDID/UAID acronyms also were not happy with the 
> aesthetics of the choice, but this was the best we could come up with.

If you prefer, and I'm NOT standing on my head about this one, you could 
go for something like Private-Context-IDentifier  (PCID), because I 
think that is really what is being described here.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 09:23:30 -0700

Eliot Lear wrote:
> user but is not the user.  

UAID is an identifier.  In computing contexts such as DKIM, all identifiers 
refer to machine-based entities, possibly ones that are representing humans.

In other words, DKIM only ever deals with, or refers to, agents.

> And I'm not proposing a veto, Dave.  I'm saying, 'yuck, but okay' 

Oh.  Missed the 'okay'.  Thanks for the clarification.

> think that is really what is being described here.

Do you think that that label would have obvious and useful meaning to an average 
administrator who is trying to configure DKIM modules?  I don't.  I'm not even 
sure it's "really what is being described here" because the label is 
sufficiently far from language used in DKIM discussions.  Note that I'm not 
saying your assessment of meaning is wrong, but that it isn't obvious to me that 
it is right.  For an acronym, that ought to count against using it.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Mar 2009 12:34:42 -0400

Humorous (maybe) and meaningless (definitely) side-comment, here,
because we need to maintain levity as well as progress:

> My personal preference for best acronym used by the

Back in the early days of IBM's TOOLS system and "the forums" (see my
blog entry at http://staringatemptypages.blogspot.com/2009/03/leiba-lament.html
for more background on that), the program used for posting forum
entries prefaced quotes from earlier entries with the email address of
who said it -- "LEIBA at YKTVMV", for instance.  One guy modified the
program to resolve the address from his personal address book ("NAMES
file") if it could, so it would say something like "Barry Leiba"
instead.  Much more friendly, he thought.

Only, not everyone agreed.  For one thing, people were used to it the
other way, and they could more readily see who said what if it always
appeared the same.  For another thing, the guy didn't always put
people's *names* in his NAMES file.  Lots of them were nicknames, such
as "August Founder" or "Great Descriptivist Satan", and that wasn't
always helpful.  But he insisted on using his version.

Someone else started referring to the guy's practice as "Let the
Buggers Eat My NAMES File Entries and Like It", which got abbreviated
as "LtBEMNFEaLI".  We decided that it would be pronounced "light-beam
feelie", and that it sounded like a mantra.

Thank you for listening.  I now return you to the Argument Clinic
sketch, already in progress.

Barry

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Mar 2009 17:40:36 +0100

Just on this point:

> Do you think that that label would have obvious and useful meaning to 
> an average administrator who is trying to configure DKIM modules?  I 
> don't.  I'm not even sure it's "really what is being described here" 
> because the label is sufficiently far from language used in DKIM 
> discussions.  Note that I'm not saying your assessment of meaning is 
> wrong, but that it isn't obvious to me that it is right.  For an 
> acronym, that ought to count against using it.

I like a choice that isn't even close to any of the other terms.  That 
way they're easily separable.  I fear it's inevitable that Identifier 
has to be in there somewhere, or I'd get rid of that too.   But as UA 
really has taken up cognitive space, it alone is worth shooting.  Again, 
if you don't like the term I picked, that's okay.  I really ought to not 
have presented one.

What I meant was simply this: the value of i=, or r= for that matter, is 
meant to be private or opaque.  My problem was that I really REALLY 
really wanted to avoid OID ;-)

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Mar 2009 12:43:58 -0400

Actually responding to the thread this time, as a participant...

> refer to machine-based entities, possibly ones that are representing humans.

The only concern I have here is that because "user agent" has a
specific connotation, there could be confusion about what happens to
it when a user uses more than one UA.  Suppose I use Gmail's web
client, Mulberry, Apple Mail, and Thunderbird, all at different times,
and all sending mail as <[email-masked]> through Gmail's
email infrastructure.  (In fact, that *is* the case.)  Should the UAID
that Gmail sticks in the signature always be the same, because it's
just me, using these client programs interchangably?  Should it be
different for all of them, because they're all different UAs?  Should
the webmail version use one UAID, and the others use another, because
there are only two submission mechanisms involved (web vs SMTP to port
587)?

I can see that someone implementing or configuring a system wouldn't
be sure how to set this up, and at least part of the confusion would
be due to interpretation of "user agent".

I also agree that we should spend too long on this point... again,
speaking as a participant.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 10:13:18 -0700

Barry Leiba wrote:
> just me, using these client programs interchangably? 

I think this mostly confuses implementation with architecture.

Simple test:  Are you using/getting different email addresses when you use these 
different modes of access?  Probably not.

That said, note that John Levine's description of his signing model nicely 
provides an example of having different UAID values, depending on the author's 
means of access.  In this case, he's decided that there is in fact some real 
utility in making exactly the distinction you raise.  So it's plausible, but no 
it's not necessary.

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Mar 2009 10:27:01 -0700

Dave CROCKER wrote:
>
> One of the tricks in choosing labels is to make sure they each have
> useful meaning, but also that they are different enough to avoid
> confusion.  Labels are intended to have mnemonic benefit.
[...]
> So the UAID term reflects the exact language of RFC 4871 that defines
> the identifier:  user or agent.

There's a significant difference between "User Agent" (as in Mail User
Agent) and "user or agent".  It is wrong to give the impression that the
MUA is doing the signing, or that the MUA is being identified by this.
>
> If the term is changed to "signing identifier" it will be semantically
> wrong and mnemonically confusing.  Wrong because it's not the domain
> doing the signing, per the definition of SDID, and confusing because
> the term is almost identical to SDID.

I'm open to other ideas, but "signing identifier" is a lot less
semantically wrong than "user agent identifier".  And I hadn't proposed
a mnemonic yet (SID is over used).  4871 currently uses "signing
identity" which isn't excessively lengthy; "signing identifier" is more
precise terminology and I'm not sure it needs an acronym either.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Mar 2009 10:33:18 -0700

> be due to interpretation of "user agent".

I share this concern, because I use at least three MUAs (at Cisco, that
is...more at home).  We don't want to give the impression that the
choice of MUA is necessarily reflected in the i= value.
> speaking as a participant.

Yes, by all means let's spend too long on this!  :-)

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 11 Mar 2009 10:38:10 -0700

> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?

I believe the Chairs requested that the other, non-controversial, errata
be incorporated into this draft.  Is that (editorial) work ongoing?

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 17:53:23 +0000

Jim Fenton wrote:
> be incorporated into this draft.  

I think we suggested it as an option rather than requested.

> Is that (editorial) work ongoing?

I think it'd be great if Dave were willing to do that, but I could
understand if he'd rather not.

S.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 10:57:50 -0700

...
>> draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.

That does not mention a bis and it does not cite the items sitting in the RFC 
Editor's Errata queue.

I think there is some confusion about the resolution of 
draft-ietf-dkim-rfc4871-errata with the development of RFC4871bis.  And while 
there has been some reference to a bis effort, it's been consistently -- and I 
believe correctly -- kept separate.

Let's resolve the draft-ietf-dkim-rfc4871-errata content issues and then move on 
to focus on a bis effort.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 10:59:36 -0700

> understand if he'd rather not.

I'm fine with continuing to edit the draft-ietf-dkim-rfc4871-errata for the 
working group.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Mar 2009 15:20:33 -0400

>Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?

I won't propose any.  I don't have time to do a proper job of rewriting it.  I think it alters 
the IETF conensus view via errata and adds needless complexity.  

Silence or lack of change proposals does not equate to thinking the current draft is good.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Mar 2009 13:45:47 -0700

> Silence or lack of change proposals does not equate to thinking the current draft is good.

+1

I think it's rather premature to presuppose that we have any sort of
consensus about any -bis changes as the people that those changes affect
are most likely completely clueless that a -bis document is even on the
working group's agenda. AFAIK it is not even in the _charter_, so how
could a more casual but interested party be expected to know?

At the very least, it seems to me that this decision can wait for
the meeting next week to get a sense of the room. Rechartering
and an update to the DKIM wg web page also seems like a prerequisite
to making -bis changes. After all, this working group was all but
winding down a month or two ago.

	Mike

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Mar 2009 17:05:23 -0400

Somewhat whimsically but wholly serious: Would simply changing the
acronym to AUID (for Agent or User IDentifier) avoid mistaken
connotations associated with User Agents (UAs)?

	Tony

---

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Mar 2009 15:23:45 -0700

> connotations associated with User Agents (UAs)?

+1 for the easy fix.

Cheers,
   Steve

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Mar 2009 18:24:38 -0400

> connotations associated with User Agents (UAs)?

WFM.

Barry

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 12 Mar 2009 06:37:07 +0530

+1

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 Mar 2009 07:56:28 -0700

Is anyone  /against/  using AUID?

d/

-- 

   Dave Crocker

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 12 Mar 2009 11:30:37 -0400

+1

---

From: Al Iverson <[email-masked]>
Date: Thu, 12 Mar 2009 11:06:56 -0500

+1

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Mar 2009 10:12:03 -0700

I'm still not convinced that adding acronyms makes the document clearer,
but AUID seems fine to me.

-Jim

---

From: [email-masked] (Wietse Venema)
Date: Thu, 12 Mar 2009 14:09:34 -0400 (EDT)

> >>> connotations associated with User Agents (UAs)?

+1 Looks good to me.

	Wietse

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Mar 2009 19:51:04 +0100

> Is anyone  /against/  using AUID?

In so far as we cannot avoid a new acronym, I am not against AUID.

Eliot

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 12 Mar 2009 15:02:08 -0400

>In so far as we cannot avoid a new acronym, I am not against AUID.

+ 1

Scott K

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 13 Mar 2009 14:34:44 +0100

+1

-- 
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: Dave CROCKER <[email-masked]>
Date: Fri, 13 Mar 2009 08:11:19 -0700

Folks,

Two days later. Still haven't seen any other issues raised with the draft.

d/

-- 

   Dave Crocker

---

From: DKIM Chair <[email-masked]>
Date: Fri, 20 Mar 2009 02:22:25 -0400

My apologies for the delay in this; I meant to send this early this week, after 
getting back in town, but... then I didn't get to it.

The chairs appreciate the view that the "errata" draft makes a lot of changes. 
Nevertheless, the view that those changes are too great... is quite a minority 
view.  The only concrete objection we've seen in this latest round is about the 
"UAID" term, and that appears to be resolved by making it "AUID".

Beyond that, I've seen no clear objections and no alternative text proposed. 
Rough consensus appears to be with the "errata" draft, with the "AUID" change 
made to it.  So there it is.

We have time on the agenda next week for discussion of this, and I think that 
item will be brief.  We have consensus on this text -- and yes, I note that it's 
given only grudgingly by some.  I expect to spend the face-to-face time in 
getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), 
and in discussing where ADSP is and how to proceed on that.

Barry

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Mar 2009 07:30:02 -0700

> made to it.  So there it is.

   Um, the reason I didn't say anything is because of how the question
   was phrased. Rather like: "would you prefer your poison on the rocks,
   or straight up?". As I've said many times, the non-Crocker-inserted
   parts of the errata are not controversial. Nuking his parts in the
   entirety would be by far the most expeditious and would easily fit
   within the errata framework.

   Only having the choice of a poison pill or nothing just plain sucks.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Mar 2009 07:56:05 -0700

> "UAID" term, and that appears to be resolved by making it "AUID".

The question of whether the "errata" draft's changes are too great
relates to whether it can be processed using the errata process or
whether it requires IETF rough consensus.  However, in
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled
that it requires IETF rough consensus because it might differ from the
intended consensus when RFC 4871 was approved.  So isn't the question of
the size of the changes moot?

> made to it.  So there it is.

I still owe the list a more extensive set of comments, which I had
promised "in a few days".  I will send those today.

> and in discussing where ADSP is and how to proceed on that.

Based on Pasi's comments, I had thought we were going the RFC route.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Mar 2009 12:55:44 -0400

> OK, now I'm confused. Can someone define IETF rough consensus? The errata had
> a 2/3 majority after the last round of discussion... does the IETF ever get a better
> consensus than that?

Pasi's point is that what you're quoting is from the DKIM working
group only, and, at that, only from some 20 participants or so.  There
are a lot more people who participate in the IETF, and the normal
process of review by the IESG and IETF last call provides the
opportunity for many more people to review and comment on the
document.

Barry

---

From: "Siegel, Ellen" <[email-masked]>
Date: Fri, 20 Mar 2009 12:41:26 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jim Fenton [[email-masked]]
Sent: Friday, March 20, 2009 10:56 AM
To: DKIM Chair
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Moving to      consensus       on      draft-ietf-dkim-rfc4871-errata

> Based on Pasi's comments, I had thought we were going the RFC route.

Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to make really
sure that's the only option. Letting the Errata go through as errata and then following
up with the -bis seemed like the best option to me... something gets out quickly, and 
then the more complete update follows. 

I'm hoping we can have some discussion around this next week. 

Ellen

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Mar 2009 10:20:35 -0700

> made to it.  So there it is.

I've placed a revised draft errata at:

    <http://dkim.org/#sign>

which associates it directly to the original signing spec, RFC 4871.

It does the string replacement for AUID and it has a NOTE indicating working 
group approval.

>       I expect to spend the face-to-face time in 

Right.  "non-IESG-approved" is important phrasing.  Folks might realize that 
anyone can post anything they want under the errata mechanism.  The issue with 
IESG approval affects the status label that is associated with that entry. 
Anything other than "Rejected" is likely to serve our purposes, until the change 
is folded into RFC4871bis.

On the matter of whether to issue the Errata under Errata or defer its release 
further, we should consider how long the delay is likely to be, especially given 
the unspecified scope of RFC4871bis.

Some folks assume that the scope is trivially small, but a bis effort that is 
seeking Draft status can -- and, IMO, should -- carefuly review the 
specification and remove what has proven extraneous.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Mar 2009 10:32:49 -0700

> a 2/3 majority after the last round of discussion... does the IETF ever get a better

There's a difference between "IETF rough consensus" versus "Working Group rough 
consensus".  The vote we just took measures the latter.

To evaluate IETF consensus requires an IETF-wide Last Call and an IESG 
assessment of the results.

>> Based on Pasi's comments, I had thought we were going the RFC route.

Well, he has a preference for /only/ going that route, but he can't actually 
veto our issuing the Errata under the Errata mechanism.  Anyone can post 
anything they want under the Errata mechanism.  Some pretty silly stuff has 
gotten posted, over the years.

What Pasi /can/ do and has done is offer his assessment of the likely IESG 
decision about the /status/ that would be assigned to the Errata.

In particular, he has a reading of the IESG rules for Errata which says that 
anything that is controversial cannot be "approved".

Unfortunately, I think his interpretation of the relevant rule's text is 
reasonable, based on the latest explanation he provided.  I think it's a bad 
rule and should be changed, but dealing with that is different from debating his 
interpretation. In other words, I think he's providing a reasonable 
interpretation of a bad rule and that, for now, we have to live with it.

The alternative labels available to our Errata, if issued through the Errata 
mechanism, are "rejected" and "hold".  In my view, "hold", with text  in the 
Errata that states there is working group consensus, is sufficient.  Not ideal, 
but sufficient.  It provides an official publication channel sooner, rather than 
later.  Given wg approval, we aren't likely to see the label "rejected" get 
assigned...

+1

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Mar 2009 09:57:30 -0700

> made to it.  So there it is.

There have been suggested changes to the text that was made  
previously.  There did not seem to be a reason to repeat the same  
objections and proposed changes when there did not appear to be  
agreement on going forward with portions of the errata that change  
prior definitions.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Mar 2009 10:14:02 -0700

On Mar 20, 2009, at 9:55 AM, Barry Leiba wrote:
> group only, and, at that, only from some 20 participants or so.   
> There are a lot more people who participate in the IETF, and the  
> normal process of review by the IESG and IETF last call provides the  

The concern seemed more related to making definitional changes to an  
an RFC within an errata.

-Doug

---

From: SM <[email-masked]>
Date: Fri, 20 Mar 2009 11:38:59 -0700

>a 2/3 majority after the last round of discussion... does the IETF 

The Standards Process requires that a proposed standard be reviewed 
by the IETF community to establish whether it has the 
consensus.  This Working Group, for example, is only a subset of the 
IETF community.  The Working Group can be used to to determine 
whether it is worth asking the IETF community to review a 
proposal.  However, it cannot act as a substitute for the IETF community.

There isn't a formal definition of "IETF rough consensus".  From the Tao:

   "a simple version is that it means that strongly held objections 
must be debated
    until most people are satisfied that these objections are wrong"

Regards,
-sm

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Mar 2009 12:22:36 -0700

> gotten posted, over the years.

I believe that what Dave is suggesting is an end run around the IESG.
In which case, I suggest that the working group insist on s/our/my/g;
above so that it has similar status.

		Mike

---

From: "Siegel, Ellen" <[email-masked]>
Date: Fri, 20 Mar 2009 16:30:13 -0400

Thanks, all, for the clarification. I read too quickly and missed the semantic distinction between "IETF consensus" was and "IETF working group consensus".

Ellen

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of SM
> Sent: Friday, March 20, 2009 2:39 PM
> To: DKIM Mailing List

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Mar 2009 16:42:30 -0400

Mike says...
>> Well, he has a preference for /only/ going that route, but he can't
>> actually veto our issuing the Errata under the Errata mechanism.  Anyone can
>> post anything they want under the Errata mechanism.  Some pretty silly stuff
>> has gotten posted, over the years.
>

Mike, I take what you're saying to mean that you don't think the
working group is behind "an end run around the IESG", and that the
errata should not be saying that it is.

What path we take to publish the errata beyond the ID that it is now,
and whether the WG is behind publishing it without Pasi's (or the
IESG's) approval, are things we'll be discussing in San Francisco and
on the mailing list.  I hope that when we leave SF we'll have most of
the answer to these, which answer we'll confirm on the mailing list.

I think we need the high-bandwidth discussion, with Pasi in the room
and responding, to get this point resolved in a way that doesn't leave
everyone waving scimitars at everyone else.  We need to be discussing
things productively as we go into final processing of ADSP and into
4871bis and Draft Standard consideration.  (I'm going to try to get a
conference call set up and use Skype and a microphone to allow remote
participants to talk.  I know we've failed at that before, but I want
to try again.)

So while I'm on the cooperation and productivity bit....
To everyone: Please say what you mean calmly and clearly, so there's
less chance of misunderstanding or the taking of offense where none
was meant.  And please don't mean offense, either, of course.  "Digs",
snarkiness, and passive-aggressiveness won't keep us moving forward.

Barry

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Mar 2009 13:59:13 -0700

> errata should not be saying that it is.

Close. I'm saying that it toes the line of completely inappropriate
for a _working group_ to consider an end run around the IESG, and
that we ought not consider that as an option for the working group.

		Mike

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Mar 2009 14:44:03 -0700

> snarkiness, and passive-aggressiveness won't keep us moving forward.

Barry, what prompted this?

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Mar 2009 14:10:56 -0700

On March 10, 2009, I wrote:
> I can do that, but it will probably take a few days.
Here are the rest of my comments on the draft.  My comments are based on
draft-ietf-dkim-rfc4871-errata-02 with the additional change from UAID
to AUID.  Perhaps "user or agent" should also change to "agent or user"
but I'm neutral on that.

0. Change the title to "RFC 4871 Update" if it is not being processed
using the errata process per Pasi's comments.

=====

1. Introduction.  The introduction, particularly paragraphs 2 and 3,
assert that the payload (the output of DKIM verification) is only a
validated signing domain.  The output of DKIM verification is
considerably more than that:  there are a great many values, such as the
list of signed header fields, that may be useful to an assessor and that
must be made available to the assessor if the verifier is to be as
interoperable with as many assessors as possible.  Furthermore, not
requiring a verifier to output unknown tag/values makes DKIM
non-extensible:  What's the point of adding new tag/value definitions if
all the verifier is going to output is the SDID?

RFC 4871 somewhat narrowly defines a protocol between the signer and
verifier.  It does not define the semantics of everything that DKIM
might convey; that was left for the overview and/or operations
documents.  To say that RFC 4871 has the potential for non-interoperable
interpretations of how DKIM operates is to criticize the specification
for something that is out of its scope.

Suggested change:  Replace everything beginning with paragraph 2 of the
introduction with the following (and delete the remainder of the
introduction):

NEW:

Hence, DKIM has a signer that applies a signature to a message, a
verifier that confirms the signature, and DKIM interfaces with an
assessor what consumes the validated signing information.  This document
attempts to clarify the meaning of identifier fields appearing in the
DKIM signature to arrive at a more consistent use of these fields by
verifiers.

=====

6. SDID definition

I am confused by the definition of the SDID as opaque.  This makes it
sound like it's a pseudonym for the actual signing domain.  The fact
that it's possible to look up information about the SDID using DNS
doesn't seem opaque to me.

OLD: A single, opaque value that is the mandatory payload output of DKIM

NEW: A single value that is a mandatory payload output of DKIM

=====

7. AUID definition

Portions of the AUID are opaque, but not the whole thing because it has
to have a specified relationship with the SDID.  I would also clarify
that there is always an AUID, even if it isn't explicitly specified in
the signature and takes its default value.

OLD: A single, opaque value that identifies the user or agent on behalf
of whom the SDID has taken responsibility.  It is specified in Section 3.5.

NEW: A single value that identifies that agent or user on behalf of
which the SDID has taken responsibility.  The AUID has the syntax of an
email address, although the local-part and any subdomain of the SDID
which is used are opaque values which may not actually exist nor have
any relationship with other identifiers in the message.  It is specified
in Section 3.5.  The AUID takes the default value specified if it is not
explicitly present in the signature.

=====

8. Identity Assessor

The term is imprecise:  it is not assessing an identity but a message. 
Suggest replacing this name with just "assessor" as is used in the
Introduction.

=====

9. d= tag definition

The corrected text removes the required relationship between the SDID
and the AUID, which is perhaps repetitive of information in the i= tag
definition, but which we felt important to repeat in the original
document for emphasis.  The narrative about "conventions and semantics"
does not belong in the normative text describing the tag, and I'm not
clear what it's trying to say in any case.  The text also repeats much
of the wording in the definition of SDID about claiming responsibility
and such.

NEW:

The SDID of the signing entity (plain-text; REQUIRED).  This is the
domain that will be quieried for the public key.  The SDID MUST be the
same as or a parent of the domain in the AUID (the "i=" value, as
described below) and MUST meet the requirements for parent domain
signing described in Section 3.8.  When presented with a signature that
does not meet these requirement, verifiers MUST consider the signature
invalid.

=====

10. i= tag definition

paragraph 2, simple change:

OLD:

value of the "d=" tag.

NEW:

SDID.

[There are probably many more places in 4871 where words like this could
be changed to the new terminology.  Should this update those as well,
for clarity?]

=====

11. Signing by Parent Domains

Small change, also in the original text:

OLD:

domain of the AUID ("i=" flag)

NEW:

domain of the AUID ("i=" value)

=====

12. Relationship between SDID and AUID

This is another place where I'm having a problem with the premise that
all a verifier needs to output is the SDID.  This section is engaging in
considerable discussion about the relationship of the SDID and UAID to
each other and to other header fields, most of which is not actionable
by implementers of the DKIM base specification and in any case is
covered elsewhere in the specification.

I'm tempted to recommend just removing this section, but perhaps there
is a little bit to say here.  Here is what I would say:

NEW:

The SDID and AUID represent two different identifiers that may be
relevant to assessors.  Unlike the SDID, the AUID, or parts of it,
represents an assertion on the part of the signer whose meaning is not
defined by this specification.  The various constraints specified for
the AUID, principally the requirement that the domain part be a
subdomain of the SDID, are intended to prevent signing domains from
making an assertions about agents or users with which they are
unaffiliated.  The assessor MUST consider AUID values in the context of
being an assertion:  an untrusted signing domain MAY make any assertion
it wishes for the AUID subject to the constraints of Section 3.8.

The AUID local-part and any subdomain of the SDID used in the AUID are,
in general, opaque.  Signing domains MAY make specific practices known
regarding their use of the AUID, such as that it does represent an
actual email address, but in the absence of such assertions MUST NOT be
assumed by the assessor.

=====

15. MUA Considerations

I find both the original and corrected text to be too specific here,
because as it says this is a matter of continuing research.  And there
isn't really any "tendency" at present.  So I would adjust the corrected
text to say:

One option is to have the MUA highlight some identifier associated with
the signature in an attempt to represent the identity that is claiming
responsibility for the message or on whose behalf the message is signed.

=====

Appendix A.

Since the list of names here is likely to be interpreted as an
endorsement of this draft, I request that my name be removed.

=====

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Mar 2009 17:56:51 -0400

> Barry, what prompted this?

Nothing terribly special... mostly two points:

1. The way Mike made his point left lots of room for people to take it
in different ways, and I wanted to remind folks to be clear.

2. Over time, various participants have angered various others, often
leading to offline (and sometimes online) complaints.

I just wanted to use the opportunity to remind everyone that snark
doesn't help, even if it momentarily makes one feel good.  The
reminder wasn't addressed specifically.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Mar 2009 17:41:11 -0400

>snarkiness, and passive-aggressiveness won't keep us moving forward.

Then in the spirit of plain speaking:

I do think that the current draft attempts to alter IETF consensus via the erata process in a way that is inappropriate.

While I think that Mike's objection was formulated in a way that unfortunately strucutred around personality, I agree that the content to which he was referring should be dropped from an eratum and addressed when the RFC is revised.

Scott K

---

From: John Levine <[email-masked]>
Date: 20 Mar 2009 23:59:20 -0000

> The output of DKIM verification is considerably more than that:
> there are a great many values, such as the list of signed header
> fields, that may be useful to an assessor and that must be made
> available to the assessor if the verifier is to be as interoperable
> with as many assessors as possible.

We seem to have a fairly basic disconnect here.  As far as I'm
concerned, an assessor has better things to worry about than the
internal details of the signature. Trying to reverse engineer or guess
what the signer had in mind would be a hopeless swamp even if it were
desirable.

Sure, it's possible to put on a worthless signature that leaves out
crucial headers, but signers who do so won't get a very good
reputation so the problem should be self-limiting.  There's no
existing installed base of inept signers we have to work around, and
it would be a poor idea do anything that would allow crummy signatures
to appear to work.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Mar 2009 18:16:07 -0700

> it would be a poor idea do anything that would allow crummy signatures
If assessors can't be bothered, then how will reputation systems know the
difference? You really can't have it both ways.

In any case, this is a false dilemma; it's not just "crummy signatures" 
at issue.
And what you call a "hopeless swamp," I call "RFC 4871."

       Mike

---

From: "John R. Levine" <[email-masked]>
Date: Sat, 21 Mar 2009 01:26:54 +0000 (GMT)

>> desirable. ...

> difference?

Sorry, but I have no idea what the antecedent to this question is supposed 
to be.  The difference between what and what?

Assessors know whether a message is signed, and if it has valid 
signature(s), the domain(s) that signed them.  All that other stuff in the 
signature is implementation details.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Mar 2009 18:38:57 -0700

John R. Levine wrote:
> Sorry, but I have no idea what the antecedent to this question is 
> supposed to be.  The difference between what and what?
>
>
>

> it would be a poor idea do anything that would allow crummy signatures

If assessors can't be bothered to assess the supposedly
"self-limiting" "implementation details", then reputation 
systems can not take them into account. By definition.

> signature is implementation details.

RFC 4871 gives no precise definition of what an "assessor"
can use to make whatever decisions it wants to draw from
the message *and* the signature(s). That you have a particular
use case in mind that doesn't care about "implementation
details" does not and should not imply that that is the only
valid use of DKIM information. That is why the errata is so
wrong headed.

		Mike

---

From: "John R. Levine" <[email-masked]>
Date: Sat, 21 Mar 2009 01:49:43 +0000 (GMT)

> If assessors can't be bothered to assess the supposedly "self-limiting" 
> "implementation details", then reputation systems can not take them into 
> account. By definition.

Right.  That's a feature.  It's not my job to work around or even identify 
crappy signatures.  If there's junk in your signed mailstream, I'm not 
likely to accept your mail, regardless of how it got there.  I have no 
interest whatsoever in trying to pick apart signatures and guessing which 
ones are particularly gnarly and which ones are sort of froody.  They're 
either valid or they aren't, per 4871.

> RFC 4871 gives no precise definition of what an "assessor" can use to 
> make whatever decisions it wants to draw from the message *and* the 
> signature(s).

Right.  That's why we're clarifying it.

R's,
John

PS: So if if I'm wrong and assessors are going to use implementation 
details, how do you expect them to use the fact that this message has a 
signed Cleverness header?  Please be specific.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: HLS <[email-masked]>
Date: Fri, 20 Mar 2009 22:36:21 -0400

+1

-- 
hls

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Mar 2009 22:18:55 -0700

> what the signer had in mind would be a hopeless swamp even if it were

On the other hand, we definitely don't have enough information about
assessors to know what information they need.  Saying that the SDID is
the only thing they can depend on getting from the verifier is too
constraining.

> it would be a poor idea do anything that would allow crummy signatures

The "worthless signature" may not have been so worthless if one of the
header fields in question wasn't present at the time of signing, but was
added later.  There have been proposals to convey some information
relating to assessment (for example, Jon Callas's suggestion at
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011104.html ) by putting
it in a separate header field and signing it.  Are you suggesting that
whether that header field is signed or not is irrelevant to the assessor?

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: Sat, 21 Mar 2009 10:42:04 +0000 (GMT)

>> internal details of the signature. ...

> the only thing they can depend on getting from the verifier is too

As I said, we have a fairly basic disconnect here.  The whole point of 
defining a standard is to constrain the interface so that multiple parties 
can interoperate.  Every time we leave something optional or vague, it's 
going to cause implementation and operational headaches, as we've already 
seen with the confusion about the semantics of i= and whether to give the 
assessor i= or d= or both.  The more tightly we can constrain the 
interface, the better it's going to work.

If we say that assessors can look inside the signature at, e.g., what 
headers are signed, we are condemning our users to endless haruspicy, 
trying to guess what headers to sign or not to sign in order to make the 
best impression based on what they guess the assessors want. Allowing 
assessors to use whatever bits they want and assuming we'll sort out later 
what we think they mostly do is a recipe for chaos.

We really need to reset our vision from the blacklist model to whitelist. 
With blacklists, there's no fundamental difference between the behavior of 
bad guys and good guys, we're forced to use complicated ever expanding 
heuristics to try to tell the difference, and we constantly have to change 
them as bad guys adapt whatever behavior we attribute to good guys.  But 
with a whitelist model, you say here's what a good guy does, you design it 
in a way that bad guys can't fake, and you're done.  If it's properly 
designed, it doesn't have to change every time there's a slightly 
different attack, and the simpler it is, the less likely actual good guys 
are to screw it up.  Hence simple, constrained interfaces.

> header fields in question wasn't present at the time of signing, ... Are 
> you suggesting that whether that header field is signed or not is 
> irrelevant to the assessor?

That's an interesting question, with a multipart answer.  One part is that 
in retrospect, Jon's suggestion is not a great design, and if Doug or 
anyone wants to add extra stuff to a DKIM signature that is intended to be 
passed to the assessor, it'd be a lot better to invent an extra field or 
two, add it to the existing signature, and specifically say that field is 
passed along with the d= to the assessor.  This both avoids the question 
of was it there originally, and also avoids having to match up multiple 
signatures with possible multiple extra info headers.

I have my doubts about the utility of any added output, since I don't 
believe there's anything a sender can say that will inherently increase 
its merit to receivers.  The best you can do is to put in hints of where 
they might find favorable info from credible sources.  Hence the assessor 
uses the d= to look in some local database and see what it thinks of the 
domain.  It's also the way we designed VBR -- it doesn't matter whether 
the VBR-Info header is signed, because the recipient isn't going to 
believe anything it says without checking first.

I'm certainly not opposed to doing experiments, and if we find that it 
will be useful, a possible future DKIM++ that would explicitly export more 
data to the assessor.  But let's not have a freeforall now.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 21 Mar 2009 11:50:14 -0700

>the answer to these, which answer we'll confirm on the mailing list.

Pasi mentioned that the errata should not be marked as "Approved" 
using the errata process.  He proposed getting the changes through 
the normal IETF consensus process, and published using the normal 
mechanisms we use for publishing updates to IETF work.

The agenda for the upcoming meeting has an item of discussion about 
WG-approved errata vs "update" RFC vs "replacement" RFC.  It may be 
better to stop using the term "errata" or "WG-approved errata" unless 
the WG is still considering submitting the ID or a variant of it as a 
proper errata.  Let's call it "RFC update".

We had a long debate over the last month about RFC 4871.  I think 
that it is premature to consider Draft Standard.  I note that SSP and 
the Overview document were set for WGLC in November 2007 according to 
the charter.  The Deployment document is still work in progress.  It 
would be better for the DKIM WG to meet its goals before starting a 
discussion about Draft Standard.

Regards,
-sm

---

From: HLS <[email-masked]>
Date: Sun, 22 Mar 2009 04:02:23 -0400

On 3/21/09, John R. Levine <[email-masked]> wrote:

> in a way that bad guys can't fake, and you're done.

Which almost sounds reasonable, John, but worthless if there is no
HUMPH (rejection) behind that whitelist model.   When what is expected
in the good guys isn't what you get, ignoring or neglecting this state
information can be dangerous to the all parties -  receiver, the
domain and the users.   While a buddy-2-buddy blanco list system does
work,  it won't work very well in a much wider anyone-2-anyone
anonymous world.

So lets keep it simple:

Any domain who wish protection against fraud using  DKIM needs to use
a standard anchor (From:) to allow AUTHOR domains to  define what is
expected in their messages they create.

Overall, I think you mixed out the black/white methods erronously.

In the blacklist model,  I believe you might be using a model where
there isn't extra information about the sender.    The same issues
applies to a whilelist model, in fact, this can in fact present more
danger when a whitelist just accepted anything from this sender
without using some extra level of information.

DKIM and POLICY raises the bar.  Its no longer the same model.   Here
you can have more reliable  black or white listing models based on the
extra level of information.   Both black and white is the same ideas -
one rejects, one accepts.  Either can have rules. its really a point
of reference only:

Black:

    Reject all mail with Author Domains that expose Always Sign Policy and
    the message is not signed (or invalid).

White:

    Accept with a GOLD STAR all mail with Author Domains that expose
    Always Sign Policy and  the message is valid

Whats safer?

To me, the black list DKIM model.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Mar 2009 08:30:20 +0100

SM, all,

> It

This would be reaching goals for the sake of reaching goals.  I would 
note that an update isn't in the charter at all.  I'm not saying don't 
do it.  I'm saying that I would rather the group re-examine its goals 
and decide what the right approach is.  Is there a dependency on the 
proposed changes to get ADSP out the door, for instance?  What about the 
readability of the document series?  Can one simply write an update that 
attempts to cut and paste from the original without adding confusion?

And now that this is going to be a full blown update or -bis effort, 
what can be revisited?  For instance, the approach I proposed, and many 
of my objections to the approach Dave and others proposed, was based on 
the notion that we were discussing an errata document and not a 
standards-track I-D.  If we are to have a standards-track I-D, as I 
wrote quite some time ago, we have more leeway in changing DKIM.  For 
instance, what is the proper way to deal with i= as a component of the 
standard?  Should we deprecate it?

This, by the way, is one of the problems I have with the chairs' 
approach.  We (those who opposed the draft) were asked to tweak specific 
lines in the doc, while at the same time being told that the draft's 
final disposition is being changed by the AD.

I still have other concerns.  Ultimately I think there is a downside to 
being too constraining (the argument that John made earlier), that 
people will ignore the constraints.  For instance, in this case, it's 
pretty clear that many people will ignore some of the terminology and 
just take d=, Sender:, From:, and potentially l= and the length, as 
inputs to identity assessment.  And then they will use i= anyway.  
Saying otherwise, IMHO, *is* premature.  Whatever.  You're attempting to 
standardize secret sauce.  Here's news: some people's secret sauce 
tastes bad (I always disliked Burger King's myself).

  Eliot

---

From: Jim Fenton <[email-masked]>
Date: Sun, 22 Mar 2009 07:59:39 -0700

John R. Levine wrote:
>
>> The "worthless signature" may not have been so worthless if one of
>> the header fields in question wasn't present at the time of signing,
>> ... Are you suggesting that whether that header field is signed or
>> not is irrelevant to the assessor?
>
> That's an interesting question, with a multipart answer.  One part is
> that in retrospect, Jon's suggestion is not a great design, and if
> Doug or anyone wants to add extra stuff to a DKIM signature that is
> intended to be passed to the assessor, it'd be a lot better to invent
> an extra field or two, add it to the existing signature, and
> specifically say that field is passed along with the d= to the
> assessor.  This both avoids the question of was it there originally,
> and also avoids having to match up multiple signatures with possible
> multiple extra info headers.

I agree that it is better to include this information in the signature
itself, which is why draft-fenton-dkim-reputation-hint does it that
way.  But the constraints on the output of the verifier being proposed
would mean that the assessor can't depend on that additional tag/value
being available to it.  How does one "say that field is passed...to the
assessor"?  The signer certainly can't, and it shouldn't be necessary to
modify the verifier to do that.

-Jim

---

From: SM <[email-masked]>
Date: Sun, 22 Mar 2009 07:26:27 -0700

Hi Eliot,
At 00:30 22-03-2009, Eliot Lear wrote:
>This would be reaching goals for the sake of reaching goals.  I 
>would note that an update isn't in the charter at all.  I'm not 
>saying don't do it.  I'm saying that I would rather

Without goals, we don't have a clear path stating what we want to 
achieve.  I don't think that we should reach goals for the sake of 
reaching them.

>the group re-examine its goals and decide what the right approach 
>is.  Is there a dependency on the proposed changes to get ADSP out 
>the door, for instance?  What about the readability of the document 
>series?  Can one simply write an update that attempts to cut and 
>paste from the original without adding confusion?

I'll skip your question about ADSP for now.  Before doing any change, 
we should take into account its effect on the document series.

>what can be revisited?  For instance, the approach I proposed, and 
>many of my objections to the approach Dave and others proposed, was 
>based on the notion that we were discussing an errata document and 
>not a standards-track I-D.  If we are to have a standards-track I-D, 
>as I wrote quite some time ago, we have more leeway in changing 
>DKIM.  For instance, what is the proper way to deal with i= as a 
>component of the standard?  Should we deprecate it?

I agree with your point about having more leeway if we are discussing 
a Standards-Track I-D.  There has been discussions about making DKIM 
leaner by dropping some components.  If we drop i=, then we introduce 
a change that affects ADSP.

>approach.  We (those who opposed the draft) were asked to tweak 
>specific lines in the doc, while at the same time being told that 
>the draft's final disposition is being changed by the AD.

I won't question the Chairs' approach.

>I still have other concerns.  Ultimately I think there is a downside 
>to being too constraining (the argument that John made earlier), 
>that people will ignore the constraints.  For instance, in this 
>case, it's pretty clear that many people will ignore some of the 
>terminology and just take d=, Sender:, From:, and potentially l= and 
>the length, as inputs to identity assessment.  And then they will 
>use i= anyway.
>Saying otherwise, IMHO, *is* premature.  Whatever.  You're 
>attempting to standardize secret sauce.  Here's news: some people's 
>secret sauce tastes bad (I always disliked Burger King's myself).

In my opinion, people will take whatever input they view as useful 
for an assessment.  There is nothing we can do about that except to 
say "don't do it".  John Levine made a good point about interoperability.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Sun, 22 Mar 2009 08:01:18 -0700

>are to screw it up.  Hence simple, constrained interfaces.

I don't see much benefit in using DKIM for a blacklist model where we 
have to play catch-up with the "bad guys".

Using DKIM only to move from IP address to domain based reputation 
gives us IP address independence only.  It is easier to sign using 
one domain if the end-result we seek is only to create an input for a 
reputation system which assesses the sending MTA.  The downside is 
that we are replicating the current "IP address model" with its disadvantages.

>believe anything it says without checking first.

That's one way to use DKIM.  This brings us back to the question of 
whether we should constrain the specification to do that only and 
leave any other uses to extensions or experimentation.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Mar 2009 10:40:19 -0700

On Mar 22, 2009, at 8:01 AM, SM wrote:

> I don't see much benefit in using DKIM for a blacklist model where  
> we have to play catch-up with the "bad guys".

Agreed, but DKIM will likely become a hybrid of acceptance and  
provisional blocking.

> one domain if the end-result we seek is only to create an input for  
> a reputation system which assesses the sending MTA.  The downside is  

DKIM replay abuse is beginning, where i= values, as defined in RFC  
4871, offer a method to mitigate intra-domain sources.  Most larger  
domains exhibit a small percentage of abusive accounts.  When i= value  
control fails, d= values will likely be removed from unconditional  
acceptance lists, since DKIM replay defeats typical account rate limits.

The i= value offers a solution to this looming problem.  It is  
unfortunate that ADSP constrains the i= value in its effort to limit  
acceptance of g= restricted keys when the i= value is not represented  
in the From header.   If that type of signature represents a risk, it  
should be declared invalid by the DKIM base specification.  Due to  
complexities imposed by double signing, ADSP is only suitable for a  
small number of domains.  With such limited coverage, it seems  
unlikely receiving domains will expend additional resources to  
evaluate ADSP i= value compliance.

The i=value will help differentiate intra-domain message streams, such  
as those from mail-lists.  When annotation is based upon  
Authentication-Results headers, then the i= value can clarify a  
message's origination within the domain.  It is unclear how DKIM/ 
Authentication-Results headers can be safely merged with newly devised  
headers without problematic adoption of changes to three different  
specifications.

-Doug

---

From: SM <[email-masked]>
Date: Sun, 22 Mar 2009 12:06:05 -0700

Hi Doug,
>acceptance lists, since DKIM replay defeats typical account rate limits.

I prefer not to get into arguments about abuse at this stage.  I'll 
also avoid comments about "i=" on this thread.  As you agreed to my 
sentence, maybe you might agree with some parts of John Levine's 
message.  If we could iron out points of agreement and disagreement, 
it might help in moving forward.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Mar 2009 17:24:17 -0400

> Agreed, but DKIM will likely become a hybrid of acceptance and  

Likely? I'll bet it!

I think it is incomprehensible to believe systems today, including 
many own by some here, have the tolerance or will have the tolerance 
to accept anything they don't like or deem as bad, nuisance, 
especially if they can detect it and it comes with new level of 
authority to reject it, bets your boots it will happen.

Look at it this way:

     - How can you stop it?

If we don't have POLICY, there is all the evidence out there this will 
become YAWP (Yet another Wasted Protocol), another high overhead and 
bandwidth DomainKeys and with some systems already doubling it up, 
DKIM + DOMAINKEYS, even higher wasted bandwidth.

If there is no payoff, it will be ignored, just like Domainkeys.
Thus far, I see no payoff. Where is the payoff?

Dave says,

    A DKIM signature means that whoever controls the DNS
    entry for the SDID is making some responsibility for
    the message.  A random bad actor, out there in the
    wilds of the Internet, cannot use that SDID.

    This is the core benefit of DKIM.

Well, many will see the this core benefit when REJECTION and 
ACCEPTANCE was the measurable value - the payoff.  To assume
only ACCEPTANCE is the payoff, is neglecting the important of
measurable failure.

The mindset of the 80s, 90s is being repeated here that was 
erroneously written in stone in 2821:

    This specification does not further address the
    authentication issues associated with SMTP other than to
    advocate that useful functionality not be disabled in the
    hope of providing some small margin of protection against
    an ignorant user who is trying to fake mail.

Lets not repeat, by some estimate, $13-$15 billion world wide, in the 
words of Bush "under misestimation".  We don't need 1, 2, 5 nor 10 
years to realized that mail abuse will not be tolerated.  It isn't 
today. Why would DKIM make it more tolerable?

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: John Levine <[email-masked]>
Date: 23 Mar 2009 00:03:24 -0000

...

>have to play catch-up with the "bad guys".

I see no benefit whatsoever in using DKIM for blacklists.  But we need
to be careful to avoid automatically carrying the habits of blacklist
filtering into whitelist filtering.

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 23 Mar 2009 00:42:22 +0000 (GMT)

> being available to it.

Right.  You say this as though it's a bad thing, but as I've said three 
times, constraining the interface is key to interoperating.

> How does one "say that field is passed...to the assessor"?  The signer 
> certainly can't, and it shouldn't be necessary to modify the verifier to 
> do that.

I'd do it by writing up an I-D and specifically saying what to pass to the 
assessor.  Unless you expect the assessor to make an end run around the 
verifier, you're going to have to change the verifier anyway to expand the 
set of stuff it exports.

Here's a list of things that a verifier might pass to the assessor:

* The number of fields in the DKIM-Signature header
* The order of the header names in h= field
* The number of headers in the message which are out of order relative to
   their order in h=
* Whether the signature includes q=dns/txt or defaults it
* The number of characters in the DKIM-Signature header, mod 17

I hope you'll agree that it would be pretty stupid for the assessor to 
depend on any of those.  So, for a standard protocol, one where the goal 
is to allow every mail system in the world to interoperate, where do you 
draw the line for verifier outputs?  If you want to interoperate, you make 
it as small as possible, which means it's just the signing domain in each 
valid signature.  (If you use ADSP, there's also two bits of ADSP output.)

It's fine to do experiments and fool around with signatures and verifiers 
and assessors any way you want, and to propose updates to standards based 
on the results of the experiments.  But operations and experiments are 
different.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sun, 22 Mar 2009 23:05:22 -0700

John R. Levine wrote:
> Right.  You say this as though it's a bad thing, but as I've said
> three times, constraining the interface is key to interoperating.
>
>> How does one "say that field is passed...to the assessor"?  The
>> signer certainly can't, and it shouldn't be necessary to modify the
>> verifier to do that.
>
> I'd do it by writing up an I-D and specifically saying what to pass to
> the assessor.  Unless you expect the assessor to make an end run
> around the verifier, you're going to have to change the verifier
> anyway to expand the set of stuff it exports.

The verifier doesn't need to do anything with the additional field, so
if it just passes all unknown fields to the assessor it doesn't need to
change at all.  Requiring the verifier to change in order to support a
new tag/value introduces a significant barrier to the deployment of new
tags.

Consider the case of DNS resolvers.  Many resolvers can support new RR
types without modification, and for those resolvers the addition of new
RR types isn't a problem.  However, a few resolvers do require
modification, and it is because of these resolvers that it is extremely
difficult to add a new RR, contributing to the need to overload TXT. 
Let's not make the analogous mistake with DKIM.

> depend on any of those.  So, for a standard protocol, one where the
> goal is to allow every mail system in the world to interoperate, where
> do you draw the line for verifier outputs?  If you want to
> interoperate, you make it as small as possible, which means it's just
> the signing domain in each valid signature.  (If you use ADSP, there's
> also two bits of ADSP output.)

The fact that there are silly things that a verifier could pass to an
assessor does not convince me that there aren't any useful ones.

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 23 Mar 2009 10:06:22 +0000 (GMT)

We've still got a fairly basic disconnect here.

> change at all.

OK, so you're saying that the verifier should consume the fields it knows 
(let's say the fields listed in 4871), and pass along the unknown ones. 
But a couple of messages ago you said that the assessor should look at the 
existing h= value to see if an auxiliary header is signed.

It's not my goal to tie you in knots here; I'm trying to figure out what 
you have in mind.  Expecting on people who read the spec to interpret 
vague sections in ways we approve of is not likely to lead to happy 
results.  Perhaps Dave can offer a few RFC 822 horror stories here.

> Requiring the verifier to change in order to support a new tag/value 
> introduces a significant barrier to the deployment of new tags. ...

The DNS analogy doesn't strike me as a useful one here.  Nearly everything 
in the DNS except for SOA and NS is intended for the consuming 
application*, but everything in DKIM beyond the signing identity is 
intended as ingredients for a complicated recipe producing one bit**, 
signed or not.  The more stuff you allow the assessor to peek at, the more 
you encourage people to invent bogus "more signed" or "almost signed" 
heuristics that will make it harder to interoperate reliably.

> assessor does not convince me that there aren't any useful ones.

There may well be useful ones, but the way to make systems that 
interoperate is to document the useful ones and forbid everything else, 
not to allow everything and have the rule be "don't do anything that Jim 
thinks is silly."

R's,
John

* - Even in DNS, leaking internal info is bad.  Remember the arguments we 
had about SOA based tree walks for SSP, enabled by the partial leakage of 
internal DNS zone cut info to clients.

** - disregarding l= which should be a poster child for what not to do
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Mar 2009 13:28:43 +0100

> filtering into whitelist filtering.

This on its face seems like a very fair statement, and I agree with you 
that we clearly have been living in a blacklist world.  But I am not 
convinced that there is a white list world out there at this time.  
There are too many virii and too many vulnerabilities to flip a good guy 
to a bad guy extremely quickly.

Eliot

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 23 Mar 2009 12:49:59 +0000 (GMT)

> This on its face seems like a very fair statement, and I agree with you that 
> we clearly have been living in a blacklist world.  But I am not convinced 
> that there is a white list world out there at this time.  There are too many 
> virii and too many vulnerabilities to flip a good guy to a bad guy extremely 
> quickly.

You're quite right that we're unlikely to have static whitelists any time 
soon.  But I was thinking more of simple questions like "is this message 
whitelisted" versus "is this message blacklisted?"

Since bad guys are trying to disguise their identities to dodge 
blacklists, blacklisting is necessarily fuzzy and heuristic, along the 
lines of Spamassassin, and even yes/no blacklists like DNSBLs have 
heuristics about how big an IP range to list if you see a cluster of 
reports from a group of IPs.

But good guys want you to recognize them, so if we offer clear 
instructions to make a message meet whitelisting rules, senders will 
follow them.  The more options they have, the less clear it is what to do, 
and the more work everyone's going to have to do to sort out the results.

The reason that l= was a bad idea is that it changes the answer to the 
question of whether a message is signed from "yes" to "sort of".  The less 
sort-of, the better.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Mar 2009 06:43:19 -0700

John R. Levine wrote:
> OK, so you're saying that the verifier should consume the fields it
> knows (let's say the fields listed in 4871), and pass along the
> unknown ones. But a couple of messages ago you said that the assessor
> should look at the existing h= value to see if an auxiliary header is
> signed.
>
> It's not my goal to tie you in knots here; I'm trying to figure out
> what you have in mind.  Expecting on people who read the spec to
> interpret vague sections in ways we approve of is not likely to lead
> to happy results.  Perhaps Dave can offer a few RFC 822 horror stories
> here.

If you remember, I started out using Jon Callas's suggestion of adding a
header field and signing it, and you and I agreed that a better approach
is to add a new tag/value instead.  So now I'm discussing the use of a
new tag/value, and not h=.  Requiring a modification to the verifier to
support a new tag/value that is not intended for its consumption is
unnecessary and inhibits deployment of new DKIM extensions.

> The DNS analogy doesn't strike me as a useful one here.  Nearly
> everything in the DNS except for SOA and NS is intended for the
> consuming application*, but everything in DKIM beyond the signing
> identity is intended as ingredients for a complicated recipe producing
> one bit**, signed or not.  The more stuff you allow the assessor to
> peek at, the more you encourage people to invent bogus "more signed"
> or "almost signed" heuristics that will make it harder to interoperate
> reliably.

We may agree to disagree whether existing DKIM fields are useful to the
assessor, but DKIM is extensible and I can think of several things (one
of which is described in draft-fenton-dkim-reputation-hint) that might
be included in the signature and are specifically intended for the assessor.

The DNS analogy points out that there's a problem with APIs that
unnecessarily restrict information about unknown RR types, as there is
with unknown (to the verifier) tag types.

-Jim

---

From: HLS <[email-masked]>
Date: Mon, 23 Mar 2009 09:49:58 -0400

John,

I think you are mixing up various models of Black/White listing.

The one we are familar with and the one widely used een when many are
not 100% happy with it is the 3rd party Lookup IP Black List - DNSRBL.

Here, many have put their trust in a 3rd party negative reputation
assessment.  Currently this is based on IP - an inherent anchor
(input)  that is always there.  DNSRBL is, like it or not, a BCP many
use - a pseudo standard.

For white list, thus far there is no wide adoption for a 3rd party
assessment and even if there was, trusting a 3rd party good reputation
assessment is hard to accept. Even if someone was going to trust a 3rd
party assessment, the problem here, is what "anchor" or data do you
pass to the 3rd party to evaluate it.

WIth DKIM, its a different model. Now we have extra potential
information to pass to an 3rd party assessor.

However, to me, the "disconnect" to me, is at the fundamental protocol
consistency level.

You want to make this purely a WHITE LIST concept.   However, DKIM
whitelisting idea would be fundamentally inconsistent if the opposite
is not considred.

In other words, if this extra information is now used for Good
Reputation Assessment, then to ignore the condition when the extra
information is not there, it would create a loophole and high
potential to further confuse users.

Just consider, if having no extra information in the mail is not
important, when it is expected to be there by the domain, then without
a doubt, the bad guys will have a special solution to DKIM - don't
bother to sign or fake it because non-compliant DKIM mail will is
ignored.

It all goes back to Whats Expected by verifiers when they sees a DKIM
signature or lack there of.   You simply can not look for only the
golden needle (good signatures) in a hay stack of abusive mail,
finding two messages with the same domain, one is signed the other is
not and then treat the signed with some higher classificaton while
doing nothing about the unsigned.

To me, it is illogical from an engineering standpoint to ignore
failure.  It runs the risk of creating a confusing consideration for
users.

This mail is ok because it was signed, valid and stamped.  What do I
do when mail is received from the same author but its not signed or
worst, signed and broken?  I'm afraid the user will learn to ignore
the whole ieda and thats defeats the purpose of DKIM in my opinion.

While it may help DMA people who want to white list their
distributions with DKIM to help push the mail to users,  they need to
also understand that fraud from the same domains can't be ignore under
the same DKIM considerations.   The DMA might not care about that.
But the DOMAIN owner will.

On 3/23/09, John R. Levine <[email-masked]> wrote:
>> that

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 Mar 2009 06:52:24 -0700

Jim Fenton wrote:
> 1. Introduction.  The introduction, particularly paragraphs 2 and 3, assert
> that the payload (the output of DKIM verification) is only a validated
> signing domain.  The output of DKIM verification is considerably more than
> that:

The Errata draft carefully documents the basis for what it asserts.

Where is the documentation that substantiates the claim of broader functionality
that you keep making?

> verifier.

4871 defines a means of associating a domain name to a message and conveying it
with the message, so that the validator can trust its... validity.

> 6. SDID definition
> 
> I am confused by the definition of the SDID as opaque.  This makes it sound
> like it's a pseudonym for the actual signing domain.

I can't guess how you are deriving that interpretation, since the use of the
term, here, is identical with its typical use in the field, and that's not what
it means.

> The term is imprecise:  it is not assessing an identity but a message.

Imprecise?    What could be more precise than "name of the module that consumes
DKIM's primary payload"?

In any event, there is a difference between assessing the associated identity,
versus assessing a message.  The former has to do with whether the indicated
identity is believed to be a Good Actor or a Bad Actor.  The later reviews
attributes of the message, such as whether it promises a vigorous sex life, and
decides whether it is a legitimate message or an abusive one.

Entirely different functions.  The latter, of course, has nothing to do with
DKIM.  The former is the consumer of the identifier DKIM outputs.

> 9. d= tag definition
> 
> The corrected text removes the required relationship between the SDID and the
> AUID, which is perhaps repetitive of information in the i= tag definition,
> but which we felt important to repeat in the original

It was a forward reference, and yes repetitive, and it placed the requirement
into the functionality that isn't responsible for making the relationship
happen.  That is, the requirement is on i=, not on d=.  So that's where the
specification of the requirement is now placed.

Stated differently:  d= doesn't care whether i= conforms.  d= doesn't really
even "know" about i=.  On the other hand, i= is required to relate to d= by
being a sub-domain of it.

> [There are probably many more places in 4871 where words like this could be
> changed to the new terminology.  Should this update those as well, for
> clarity?]

oops.  good catch!  (I tried to fully audit the text for exactly this but pretty
much never get all the occurrences during such an exercise.  Thanks!.

> domain of the AUID ("i=" value)

Oops.  But actually, neither of us got it right.  According to 4871, it's a "tag".

> This is another place where I'm having a problem with the premise that all a
> verifier needs to output is the SDID.

Since all of the finished DKIM documents offer the deliver of an identifier as
its only goal, are you suggesting explicitly expanding DKIM's scope?

> This section is engaging in considerable discussion about the relationship of
> the SDID and UAID to each other and to other header fields, most of which is
> not actionable by implementers of the DKIM base specification and in any case
> is covered elsewhere in the specification.

The section is intended to counteract a couple of years of confusion.

> NEW:
> 
> The SDID and AUID represent two different identifiers that may be relevant to
> assessors. 

Might be, yes.  All sorts of things /might/ be relevant to the heuristic 
evaluation engine.  But that's outside the scope of DKIM.  DKIM's job is to 
deliver an identifier.

>     Unlike the SDID, the AUID, or parts of it, represents an
> assertion on the part of the signer whose meaning is not defined by this
> specification. 

parts of it???

assertion?  it's an identifier.  the only assertion the spec suggests is that it 
  can be used to identify a user -- although that's a bit problematic if it is 
only a domain name.

>    The assessor MUST consider AUID values in
> the context of being an assertion:  

There is no requirement that the assessor see it and certainly no requirement 
that the assessor process it, nevermind process it in a particular way.

> The AUID local-part and any subdomain of the SDID used in the AUID are, in
> general, opaque.  Signing domains MAY make specific practices known regarding
> their use of the AUID, such as that it does represent an actual email
> address, but in the absence of such assertions MUST NOT be assumed by the
> assessor.

They /may/ do all sorts of things that aren't in the DKIM spec.  The fact that 
it's outside the DKIM spec means it's irrelevant to the spec.  So I don't 
understand how your observation relates to the current effort.

> 15. MUA Considerations
> 
> I find both the original and corrected text to be too specific here, because
> as it says this is a matter of continuing research.  And there isn't really
> any "tendency" at present.  So I would adjust the corrected text to say:
> 
> One option is to have the MUA highlight some identifier associated with the
> signature in an attempt to represent the identity that is claiming 

For the Errata, the only change to this text was intended to reflect the 
SDID/AUID changes, rather than attack the deeper problem of having this section 
be present at all.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Mar 2009 15:19:49 +0100

On 3/23/09 1:49 PM, John R. Levine wrote:
> question of whether a message is signed from "yes" to "sort of".  The 
> less sort-of, the better.

I'm sorry- in the plethora of email that is this list, I missed your 
position on l=.  I take it from your note that it should be required or 
not at all?

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Mon, 23 Mar 2009 07:37:06 -0700

> position on l=.  I take it from your note that it should be required  

Use of l= allows anyone to copy the message, replace the content
with their own, and resend it without breaking the signature. (There
may be cases where they can't do that, but there are certainly cases
where they can).

It's the existence of it that's a bad idea. The sole redeeming feature
is that it's optional, and so receivers can treat any signature with l=
as invalid, with no risk of affecting mail sent by competent senders.

Cheers,
   Steve

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 23 Mar 2009 15:17:58 +0000 (GMT)

Hmmn, I'm starting to see the depth of the disconnect here.

DKIM iss a security protocol that allows a signer, identified by its 
domain, to take responsibility for a message.  But it appears that you're 
also seeing it as a way for a signer or a sender to attach a grabbag of 
assertions to a message.

To reiterate a point I made a message or two ago, since senders are all 
hostile and incompetent until proven otherwise, the only reasonable way to 
treat such assertions is to assume that they're all self serving lies 
and/or mistakes.  If you know you trust the signer, you may be able to 
believe the other assertions, but even if the signer is honest, they may 
have unfortunate security consequences, e.g., l= can let bad guys add 
extra MIME sections if the message isn't carefuly crafted to prevent that.

> Requiring a modification to the verifier to support a new tag/value that 
> is not intended for its consumption is unnecessary and inhibits 
> deployment of new DKIM extensions.

Right, it's a security protocol.  Making random changes to a security 
protocol is widely seen as a Bad Thing.  Maybe in the future we'll agree 
that there is other stuff that might be good to pass with the signature, 
but at the moment, we have no such agreement, and the right way to extend 
a security protocol is to design the extention and go through the usual 
review process, not just do ad hoc hacks that seem like a good idea at the 
time.

Also, please don't forget the as-if rule.  If you want to experiment with 
DKIM, you can write your code any way you want, so long as its external 
behavior matches the spec.  If you want your local verifier to export 
field names and signature length mod 17 so you can do experiments, that's 
fine, go right ahead.  But the spec as I read it says that all that's 
exported is the signing identity, and that's all a conforming 
implementation not doing an expriment should use.

R's,
John

---

From: <[email-masked]>
Date: Mon, 23 Mar 2009 09:21:47 -0400

Maybe I should read the other 22 posts before jumping in 
 
"RFC 4871 gives no precise definition of what an "assessor"
can use to make whatever decisions it wants to draw from
the message *and* the signature(s). "

correct and it should stay that way

Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Friday, March 20, 2009 9:39 PM
To: John R. Levine
Cc: [email-masked]
Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Mar 2009 11:06:17 -0700

> it might help in moving forward.

Concerns related to assessor inputs are centered upon whether to use  
i= or d= vales.  This overlooks the use of a two stage approach.

The d= value results can signal a need for subsequently resolving  
intra-domain sources using i= values, for example.  Making a series of  
assessments is fairly normal, especially when not doing so exposes  
receivers to high levels of undesired messages.  Large domains are  
unable to perfectly vet outbound DKIM messages, where each message  
that is mistakenly signed can be replayed.  When the intra-domain  
problematic sources are limited in number, feedback can be quick and  
effective.  Secondary assessment results would not need to be retained  
longer than message expiry when the signing domain responds to their  
intra-domain sources being listed.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Mon, 23 Mar 2009 20:25:46 -0700

On Mar 23, 2009, at 8:20 PM, Michael Thomas wrote:

> Steve Atkins wrote:
> Not according to the Crocker-Levine axis. All your decisions are
> belong to them.

I don't get your point. Could you clarify?

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Mon, 23 Mar 2009 20:47:44 -0700

On Mar 23, 2009, at 8:40 PM, Michael Thomas wrote:

>  Yes. With the Crocker-Levine axis, you get exactly one return value
>  from the signature evaluation -- t or nil. Anything finer grained
>  than that is illegal and verboten. If you want to make a nuanced
>  decision based on l= values, you are out of luck.

In this particular case that's not an issue. If there's an l= tag, it's
not a valid signature.

There's no point in trying to stuff everyones favorite hobbyhorse
into a DKIM signature. It's just asking for interoperability
problems. There's no real downside to simply putting your favorite
metadata in it's own header, and having DKIM sign that.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Mar 2009 20:40:38 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Mar 2009 20:20:57 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Mar 2009 21:18:19 -0700

> In this particular case that's not an issue. If there's an l= tag, it's

Incorrect. L= is perfectly valid RFC 4871; your low opinion of it is
irrelevant for the Crocker-Levine binary DKIM evaluation. If you don't
like that, I suggest you take that up with them or not support their
draft.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 23 Mar 2009 21:21:10 -0700

> like that, I suggest you take that up with them or not support their

I think you're either misreading or misrepresenting the situation.

Cheers,
   Steve

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 24 Mar 2009 10:10:04 -0000

On Mon, 23 Mar 2009 00:42:22 -0000, John R. Levine <[email-masked]> wrote:

> the
> depend on any of those.

Not necessarily. Basically an Assessor could usefully be made aware of the
fields that have NOT been signed.

But what I don't understand is why we are discussing the interface between
the Verifier and the Assessor at all. They are both part of the setup at
the site where the Signature is being examined (usually at the incoming
boundary of some target domain). And the IETF has always kept clear of
specifying protocols to be used within one site. For example, that is why
the IETF has never tried to specify an interface between whatever MTA
receives the incoming stuff over Port 25 and the storage agent (Pop3,
IMAP, Mbox format, procmail, whatever) it is to be sent to (in spite of
the fact that a standard interface at that point might be quite a useful
thing to have).

Which fields of the message header get signed is a choice to be made by
the signing domain, and should be based on its perception of what the Bad
Guys might try to gain by altering or inserting unsigned fields. Clearly,
there are some fields that it would be stupid to sign (Received obviously,
and any List-* unless you are signing in behalf of a list expander).
Clearly there are fields which is would be stupid NOT to sign (From, which
would be so stupid to omit there is a MUST to cover it, but also Sender,
To, Cc, Reply-To unless there is a good reason not to). But that is a
matter for some BCP Document, not for the Standards track. And the
interface to the Assessor is the same.

-- 
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: 24 Mar 2009 14:02:59 -0000

>   decision based on l= values, you are out of luck.

This might be a good time to step back for a minute and remember what
the point of a standard is -- it's to allow two parties who don't know
each other to interoperate.  Standards don't preclude local
arrangements that do something else, but if you want to work with the
largest possible part of the rest of the world, when you're not
talking to someone with whom you have a prior arragement, you follow
the standard.

As I recall, one of your main reasons to use DKIM is to look at
incoming mail to try and tell looped back real Cisco mail from
phishes.  In that context, you can do whatever you want, since you
only have to interoperate with yourself.  If you want to do heuristics
on message length or try to mutate subject lines to undo list tags or
anything else on mail with Cisco signatures, that's fine, it won't
affect anyone else.  If you want to try your heuristics on other mail,
nobody's going to stop you.

On the other hand, if you're sending mail to people you don't know, or
you're evaluating mail from people you don't know, it really would be
a good idea to do what the spec says.  In the particular case of l=, I
doubt that Steve and I are the only people who think its risk vastly
outweighs its potential utility, so if you want to maximize the odds
that recipients will accept your signatures, don't use it.

R's from the Axis of Interoperatbility,
John

---

From: HLS <[email-masked]>
Date: Tue, 24 Mar 2009 10:53:01 -0400

But if one doesn't agree with the specs,  you are not going to get the wide
interoperability endorsement and adoption you presume people will follow.
And I mean, across the board, not the peer group.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Mar 2009 09:40:55 -0700

> endorsement of this draft, I request that my name be removed.

Jim,

That's certainly your choice to make, but I hope you'll change your mind.

I'm responding publicly in order to suggest that the working group has had a 
continuing difficulty with reactions to strong debate and resistance to rough 
consensus decisions.  It is entirely possible to have strong disagreement that 
is constructive, rather than divisive, and I keep hoping that the DKIM working 
group can find its way to the former, from the latter.

Over the years, I've lost vastly more of these kinds of debates than I've won. 
As long as the process was full, frank and honest, then I feel that's the best 
one should hope for.  If a view that I disagree with develops rough consensus at 
that point, then I think the community need has been well served. Diversity 
ensures serious analysis.  IMO, /that/ is the community need, as input to a 
decision.

I view the Acknowledgements section as an indication of the breadth of 
contribution, not the depth of agreement.  You have most certainly contributed.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Mar 2009 13:01:02 -0400

> contribution, not the depth of agreement.  You have most certainly contributed.

I certainly agree with this, and I'd like to see those who spent a
good deal of their time, regardless of whether the result comes out
the way they'd have preferred, to get credit for their commitment to
the work.

Barry