Subject: [ietf-dkim] Requirements comment: Bigbank example description

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 12:51:26 -0400

I went through the draft and marked it up.  I'll break these up into 
individual messages for each comment.  I'll start with a context diff of the 
draft and proposed changes and then give a discussion of why...

*** 321,328 ****
     unsigned outweights the risk of illegitimate mail being delivered in
     the eyes of the sender.

!    1.  A purportedly sends to B with a missing or broken DKIM signature
!        from A

     2.  B would like to know whether that is an acceptable state of
         affairs.
--- 321,328 ----
     unsigned outweights the risk of illegitimate mail being delivered in
     the eyes of the sender.

!    1.  Mail with a RFC2822.From A is sent to B with a missing or broken
!        DKIM signature

     2.  B would like to know whether that is an acceptable state of
         affairs.
***************

I think that saying mail with an RFC2822.From A is clearer than A purportedly 
sends.  Also, Purported is used in Sender ID PRA (Purported Responsible 
Address) and so use of that word in this context might be confusing for some.

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

---

From: Tony Hansen <[email-masked]>
Date: Wed, 09 Aug 2006 14:34:52 -0400

> draft and proposed changes and then give a discussion of why...

-1

I want companies such as eCard senders or News Agencies to be able to 1)
send a message on my behalf while 2) marking themselves as the sender
and 3) being able to sign the message. This minimally requires support
for RFC2822.Sender as well as RFC2822.From.

I *would* support changing it to

    1.  Mail with a RFC2822.From or RFC2822.Sender A is sent to B with a
	missing or broken DKIM signature

This has nothing to do with PRA and its support for Resent-From and/or
Resent-Sender.

	Tony Hansen
	[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 15:17:12 -0400

> This has nothing to do with PRA and its support for Resent-From and/or
Agree it has nothing to do with PRA, that's why I say don't use the word 
purported.

Since many popular MUAs do not display Sender, including Sender defeats nearly 
the entire purpose of the Bigbank example.  I think what you would want then 
is the DKIM signing complete practice.

I think we went around several times on From or From/Sender and there was (in 
my opinion, which I know counts for exactly nothing) a reasonable rough 
consensus that From was what we should focus on.

Keep in mind that the Big Bank example is explicitly about phishing targets 
that are willing to accept breakage of some legitimate e-mail functionality.  
That doesn't sound like your case.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 01:32:35 +0200

Tony Hansen wrote:

> This has nothing to do with PRA and its support for
> Resent-From and/or Resent-Sender.

If there is an SSP for "A", why apply it to Sender "a@A",
but not Resent-From "a@A" ?  

Can you use an SSP for "B" and 2822-From "b@B", if the
mail was actually Resent-From "a@A" ?

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 00:52:38 +0100

Frank,

> mail was actually Resent-From "a@A" ?

Can I suggest making concrete proposals, aimed at moving
towards consensus, rather then asking open ended questions
that lead to lots of repetition and lots and lots of mail?

Really - it'll lead to less hassle for us all,

Thanks,
Stephen.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 02:32:26 +0200

Stephen Farrell wrote:
 
> towards consensus

It won't help if I reject three proposals "add 2822-Sender"
only because I don't understand it.  It also won't help if
I'd support it, but have no clue why Resent-* are excluded.

Frank

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 20:46:17 -0400

> I'd support it, but have no clue why Resent-* are excluded.
Here is a concrete proposal....

In this round, we only specify sender policy for 2822.From.  To the extent we 
have consensus that SSP is a good thing, we have consensus that it should 
cover 2822.From.  Once you get beyond that, consensus is elusive at best.

There is a requirement that the protocol be extensible.  Later, if there is a 
demand, something else could be added.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 21:29:19 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 7:52 PM
Subject: Re: [ietf-dkim] Re: Requirements comment: Bigbank example
description

> Really - it'll lead to less hassle for us all,

If this may help, and Michael can comment and clarify, an old pseudo-code
presented here (or in the old list) did include consideration for the
2822.Sender header:

$outsideheaders = "From, Sender";
$from = ; // 2822 From: address in msg

dkim_bindToOutsideHdrs () {
   foreach ($hdr in $outsideheaders) {
      if (dkim_bindToHdr ($hdr) == BIND) {
         if ($hdr != "From") {
            $policy = dkim_signerPolicy (domainpart ($from));
            if ($policy == strict || $policy == nomail)
                return FAIL;
            else
                return PASS;
         } else
             return PASS;
      }
   }
   return NEUTRAL;
}

In layman terms (pending Michael's confirmation)

    The SSP policy was ALWAYS done on the 2822.From domain
    but ONLY when the DKIM-Signature d= tag was bound to
    the 2822.Sender domain.

It was my contention that the SSP should ALWAYS be done against the
2822.From regardless of how DKIM-Signature domain was bounded.

It was from my analysis of Michael's initial pseudo-code that started my
efforts in producing the Policy vs. Verification Result tables and the
genesis of the more restrictive policy concepts.

Hope this provide some insight.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 22:07:27 -0400

> 2822.From regardless of how DKIM-Signature domain was bounded.
+1

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 22:35:24 -0400

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>

> In this round, we only specify sender policy for 2822.From.
> To the extent we have consensus that SSP is a good thing, we
> have consensus that it should cover 2822.From.  Once you get
> beyond that, consensus is elusive at best.
>
> There is a requirement that the protocol be extensible.
> Later, if there is a demand, something else could be added.

As shown in the pseudo-code posted in my last message, I believe the
original thinking was basically only do to a 2822.From policy lookup when
there was a 3rd party domain signature binding.

hmmmm, in fact, re-reading requirement #9, the mentality might still reflect
this original thinking:

     The Protocol MUST NOT be required to be invoked if a
     valid first  party signatures is found.

I ask for the author's confirmation or clarification on this.

Since day one, I had some concerns with this logic as it revealed some
issues regarding other possible domain Practices possible and as well as
exploitations possible.  Hence the reason for the Policy vs. Verification
tables, showing why the SSP should always be done on the 2822.From and the
beginnings of the DSAP drafts to document the reasons, method to resolve
this, and illustrating a reliable verification chart.

Also, I think by introducing 2822.Sender: this will inevitably begin to
touch base with 2821.MailFrom considerations as well and I think that will
take up into a new level of 2821 vs. 2822 issues and debates, or something
think you guys call a "Rat Hole?"  <g>

I'm not saying it is bad idea. I am just saying I think it might
force some other considerations as well for which if we want to do this, it
might probably be worth the effort.

So maybe if we can easily construct this to be able to add Sender: as an
extended implementation option without breaking the minimum requirements, I
would put my +1 to this.

But it now seems, that requirement #9 might actually reflect the original
logic intended.

I would like to know if that's true.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Aug 2006 01:42:57 -0700 (PDT)

>> 2822.From regardless of how DKIM-Signature domain was bounded.

Would you remind me how this would work with multiple address in
the From field? [*]

[*] If you answer is that only the first is looked up, you just
made it possible for me to add additional user into the system
and now instead of (or more likely in addition) to Sender field,
redirection systems and systems like airport kiosks would start
putting their own name in From and only then the user name.
BTW - I'm not saying this is bad - it may well be a good and
reasonable solution for their situations.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 06:32:25 -0400

----- Original Message ----- 
From: "william(at)elan.net" <[email-masked]>
To: "Scott Kitterman" <[email-masked]>

> Would you remind me how this would work with multiple address in

What's wrong with checking each one?  I mean, why allow for a loophole?

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 12:43:57 +0200

> Hope this provide some insight.

Yes.  Following your pseudo-code I get "surprising" FAILs for
the Resent-* cases:

A signed mail with "strict" SSP is Resent-From Jou User.  The
included original signature is valid, everxything works, UNLESS
Joe's mail service provider signs all outgoing mails.  Then the
resent mail would have two signatures, one by Joe's provider,
and that second signature FAILs for a "strict" SSP.

That shouldn't happen, it's completely out of Joe's control.
Aa requirement that would be:

   "The protocol" MUST be either compatible with "resent mail",
   independent of the signing practices of a resending service,
   or explicitly explain why and when that's expected to fail.

That would affect section 5 5 in the DSAP draft.

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 12:02:23 +0100

> and that second signature FAILs for a "strict" SSP.

But don't we currently have a requirement in 5.3 that says:

    9.   [PROVISIONAL] A signature that is not on behalf of the
         RFC2822.From MUST NOT be construed as suspicious for the
         purposes of The Protocol.

If that were to gain consensus (as I believe it ought, at least
since the alternative makes no cryptographic sense to me) then
would there still be a problem with Resent-* cases? If so, what
problem?

If the problem is just the pseudo-code then that can be fixed
there.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 07:32:16 -0400

----- Original Message ----- 
From: "Hector Santos" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>; 

>> Would you remind me how this would work with multiple 
>> address in the From field? [*]
> 

William,

The question is:

     Is the whole the same as the sum of its parts?

Lets consider an example:

    From: A, B, C
    DKIM-Signature: d=A; h=From: ....

Should the result be the same when viewed as three separate messages?

    From: A
    DKIM-Signature: d=A; h=From: ....

    From: B
    DKIM-Signature: d=A; h=From: ....

    From: C
    DKIM-Signature: d=A; h=From: ....

Theoretically, the answer is yes. 

The expected outcome in all cases should be the same.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 13:53:55 +0200

Stephen Farrell wrote:
 
> don't we currently have a requirement in 5.3 that says:

In the draft I read 5.3 (9) is completely different.  Which
version are you looking at ?  The "requirements-00" apparently
did not make it yet to the tools server and the DKIM page, to
the tracker, or the "official" drafts directory.

The copy I read has date 2006-08-08, and in that version the
word "suspicious" appears only in section 6.1.

> If that were to gain consensus (as I believe it ought, at
> least since the alternative makes no cryptographic sense to
> me) then would there still be a problem with Resent-* cases?

No more problem with any always-signed-Resent-cases.  But that
eliminates 5.5 in the DSAP draft with a MUST NOT.

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 13:14:15 +0100

> word "suspicious" appears only in section 6.1.

Oops - must be an earlier version Mike sent me. Sorry 'bout
that.

I guess it got deleted. Mike - what was the reason for that
change?

> eliminates 5.5 in the DSAP draft with a MUST NOT.

I'm quite sure that some requirement will contradict some aspect
of each of the current proposals, but we shouldn't worry about
that too much for now.

S.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 15:01:56 +0200

Stephen Farrell wrote:

> must be an earlier version Mike sent me.

Okay, I started to wonder if what I have might be already old.
Maybe draft-ietf-dkim-ssp-requirements-00.txt still needs your
approval for its "official" publication, because it's a "-00".

> I'm quite sure that some requirement will contradict some
> aspect of each of the current proposals, but we shouldn't
> worry about that too much for now.

I like to have it clear in the requirements, that IFF a future
SSP won't work for such "resent" scenarios, then that has to be
explicitly stated.

It's relevant for a hypothetical 2822bis, if 2822bis tries to
decree that all forms of Resent-* are obsolete and should be
replaced by ordinary forwards as MIME message/rfc822 parts.

I vaguely recall that an MMS2SMTP gateway RFC already goes in
that direction, either get rid of or ignore any Resent-*.

Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Aug 2006 06:41:50 -0700 (PDT)

> What's wrong with checking each one?  I mean, why allow for a loophole?

Wasn't one of the requirements finite number of queries?

If not then I'd like to send email with 100 different addresses in From
but all within different domains on your dns server to 10,000 random 
people. Want to guess how many requests you'll receive?

---
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 06:47:56 -0700

Sorry folks, this was a very last minute deletion on my part. The 
version that
Frank has is correct. Suffice it to say, my read of the working group 
consensus
was that the general sentiment of the wg would have favored (9) in 
Stephen's,
but I'm not sure it belonged in the requirements draft at this time, so 
I erred
on less controversy.

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Aug 2006 06:54:06 -0700 (PDT)

Most legitimate Resent cases are such where last sender (person listed
in Resent-From) would very likely be be on the personal whitelist of
the recipient because of extensive prior communication.

BTW - this means that absolute/strict policy may not be absolute in
practice where the filter manufacture may decide to use system with
whitelisting overriding any results from policy check (including
those from very strict only-me, no 3p policy).

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 09:55:20 -0400

----- Original Message -----
From: "william(at)elan.net" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Scott Kitterman" <[email-masked]>; <ietf-

> Wasn't one of the requirements finite number of queries?

As finite as required I guess.

> If not then I'd like to send email with 100 different
> addresses in From but all within different domains on
> your dns server to 10,000 random people. Want to
> guess how many requests you'll receive?

Maybe there is short circuit?

Maybe I won't even bother with such nonsense multi-address from lines, which
probably is going to break along some down stream anyway.  In all honesty,
it is rare to encounter this, IMV.

Also, consider the signature itself. Maybe as long as the hash includes the
From: and the signature is valid, maybe the minimum requirement is that such
a signer doing this must set the first address as the OA domain.  In this
case, maybe only the first address is the only that really counts for SSP
purposes.   Will that work?

IAC, I don't see this as a show stopper that's for sure.  :-)

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Aug 2006 06:55:32 -0700

Michael Thomas wrote:
>  so I erred on less controversy.

Some of us believe, rather strongly, that this is a particularly important
"bias" to the development of the requirements list.  It occurs, to me, however,
that it might not be clear whether there is working group consensus on it.

I would be interested in seeing statements of preference for, or against, having
the requirements be minimalist, and include only those items for which there is
clear rough consensus to include.

If an item engenders real wg controversy, it is *not* included.

Comments?

d/
-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 15:05:50 +0100

Michael Thomas wrote:
> Frank has is correct. 

Nope. Its my fault for not checking.

 > Suffice it to say, my read of the working group
> consensus

Fair enough. So I guess that means that maybe including Frank's
suggested requirement text would be a good idea.

As he said it:

In non-chair mode: either that, or the no-longer-there-#9, seem
not bad to me, in terms of making non-existent anti-signatures a
non-requirement. (Is that record number of negatives:-)

S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 07:13:52 -0700

Stephen Farrell wrote:

>> but I'm not sure it belonged in the requirements draft at this time, 
>> so I erred
>> on less controversy.
>
>

Perhaps what would be worthwhile here is to explicitly draw out
the list/resent scenario itself and say why it's a use case that we ought
not outlaw, and from whence a requirement is derived.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 15:16:57 +0100

> not outlaw, and from whence a requirement is derived.

Ah. I thought most of that was in his email, but sure - having the
use case in the I-D makes it easier to see what the requirement's
for. (Frank - want to write it so's Mike can cut'n'paste if the
WG adopts this?)

S.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 10:16:31 -0400

> people. Want to guess how many requests you'll receive?
Sure.  It's too many, but he legitimate use of multiple From addresses is 
rare.

We set a processing limit in the design and anything that can't be resolved 
within the processing limit fails SSP verification.  Since no SSP lookups 
will be required (based on the current requirements draft) for First Party 
signatures that verify, I don't think this is a significant limitation.

Personally, I don't think I've ever seen a multiple From message.  I don't 
think we should get to hung up about it.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 07:19:49 -0700

>If an item engenders real wg controversy, it is *not* included.
That mostly works for me. What I've tried to do is give some of the
ones that I see some but not an overwhelming consensus a "provisional"
status in the draft. I think that in order to advance we probably should
take each one of them and determine whether there is *real* consensus
with a real constiency lest it gets removed in the final version.

But yes, less is better here.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 07:21:02 -0700

> for. (Frank - want to write it so's Mike can cut'n'paste if the

Apologies to Frank if I've missed this thus far -- I'm still wading through
this morning's email and on barely the first cup of coffee...

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 10:23:40 -0400

On Thursday 10 August 2006 09:55, Dave Crocker wrote:
> "bias" to the development of the requirements list.  It occurs, to me,
> however, that it might not be clear whether there is working group
> consensus on it.
>
I think being somewhat minimalist in the design and the final specification is 
a good idea.  I think that the requirements collection process should be 
relatively open.

> I would be interested in seeing statements of preference for, or against,
> having the requirements be minimalist, and include only those items for
> which there is clear rough consensus to include.
>
Against.

> If an item engenders real wg controversy, it is *not* included.
Taken strictly enough, the only way to accomplish this is to do away with SSP 
entirely.  

The way I would approach it is along these lines:

Requirements phase:

Open to most any input.  Only those requirements for which there is a rough 
consensus to exclude or which inherently conflict with conflicts the WG is in 
favor of should be excluded.

Design phase:

The protocol should attempt to meet all requirements.  This will not be 
possible.  

As we work through the requirements, the requirements list to be implemented 
in the design should be pruned based on WG rough consensus and complexity to 
implement in design and code (i.e. if something is very simple, then I think 
a small constituency is OK).  When we run out of undesigned requirements, we 
are done.

Scott K

---

From: Damon <[email-masked]>
Date: Thu, 10 Aug 2006 11:00:39 -0400

> I would like to know if that's true.
Maybe #9 is an incomplete statement?

The Protocol MUST NOT be required to be invoked if a valid first party
signature (without the 's') is found. However, if the first party
signature if damaged in transit the Protocol MUST be invoked to
determine if any authorized domain or third party signers have signed
the message. The order in which each authorized domain or third party
signer is validated MUST NOT be specified.

Regards,
Damon Sauer

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 17:00:40 +0200

Michael Thomas wrote:

> Apologies to Frank if I've missed this thus far

Probably you didn't miss anything, the "if it outlaws Resent-*
that must be crystal clear" was all I said about it, and I've
no good idea how to add different List-issues to this point.

Maybe <http://article.gmane.org/gmane.ietf.dkim/4943/> helps 
with lists (last paragraph):

| I think there is some value in distinguishing between "I
| sign everything and never send to mailing lists and other
| known mungers", "I sign everything, but also send to known
| mungers", and "I know I don't sign everything".

Apparently the requirements don't include the last two cases
yet.  If "I sign sometimes" is the default for no SSP, then
"I know I don't sign" is relevant.

The opposite could also make sense, without SSP a default of
"I know I don't sign", otherwise an explicit "I sign sometimes"
(or better) is required.

The 5.3 (7) consensus isn't obvious:  A "null" SSP should IMO
mean something above "don't look any further".

Frank

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 11:16:25 -0400

> signer is validated MUST NOT be specified.
Since DKIM base already says damaged == no signature, I think this is not 
necessary.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 16:20:44 +0100

Damon,

There are some problems with your suggested statement. (Note:
I'm not saying I'd agree with it if its fixed, but as of now
its just not ready for the WG to consider.)

Damon wrote:
> signature (without the 's') is found. 

Ambiguous. Do you mean:

MUST NOT be invoked if any valid first party signature is found,

or,

MUST NOT be invoked if exactly one valid first party signature is
found ?

(Aside: the latter would be, IMO, silly, so I guess you didn't
mean that.)

 > However, if the first party
> signature if damaged in transit 

A signature or message may be changed in transit, or may be bogus,
but the verifier cannot know that - the verifier can only tell
that there is no good (first party) signature.

 > the Protocol MUST be invoked to
> the message. 

Nope. The verifier can tell if they've signed by looking and checking,
so s/have signed/have been flagged by the first party as acceptable
signers for/ or something like that.

 > The order in which each authorized domain or third party

Why? Seems like a nit. And I'd probably steer clear of calling
these authorized, on the basis that the term has a lot of
ancillary baggage that we don't really want to have to explain
away. (Having said that, it is a natural word to use, but not
the best technical term;-)

Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 11:25:00 -0400

> "I know I don't sign" is relevant.
For first two cases listed, I think we've organized around a different 
paradigm:

1.  I sign everything and anything without a signature from me should be 
treated as suspicious (I'm willing to suffer the consequences from message 
rejection due to signature breaking).

2.  I sign everything.

For the munger/non-munger approach, how would then domain owner know if it's 
users sent to mungers or not?  I don't see how that's possible.

For I know I don't sign, is there a special action a receiver can take if they 
get a message with a signature (maybe claranet started signing and you missed 
the message)?  If not, do we need to include it?

Scott K

Scott K

---

From: Damon <[email-masked]>
Date: Thu, 10 Aug 2006 11:40:31 -0400

> (Aside: the latter would be, IMO, silly, so I guess you didn't

Was just keeping with what was already there in #9 and expounding upon it.

> that there is no good (first party) signature.

Ok. What happens if there is a list of authorized signing domains and
one of those signs the message... then what?
 We already said that a damaged sig = no sig. We also said that a
valid signer is a valid signer.

> signers for/ or something like that.

Stealing from Phillip... aww fishpaste.. your right.

> the best technical term;-)

I wasn't too clear myself on how best to say, if an authorized domain
sig is valid over a broken first party sig, but there are multiple
authorized sigs, it should not matter which one is used, just the
first one you check and it valid is fine.

I am not a very good wordsmythe

Regards,
Damon Sauer

---

From: Steve Atkins <[email-masked]>
Date: Thu, 10 Aug 2006 08:51:59 -0700

> clear rough consensus to include.

For.

> Comments?

I would like to see DKIM deployed as soon as possible. Controversy,
overly complex requirements and meaningless chrome are some
of the things that are preventing that from happening.

(I also think that the same issues make it more likely that the final
spec will turn out, on reflection, to be flawed in production, and
that's even worse in terms of deployment.)

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 11:48:11 -0400

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 10, 2006 11:00 AM
Subject: [ietf-dkim] Re: Requirements comment: Bigbank example description

> "I know I don't sign" is relevant.

If I'm catching what you saying, -1 from a "Author of Software" POV.

Knowing you don't sign, and one if found, is strong evidence of a policy
failure.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 12:16:12 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: "DKIM List" <[email-masked]>
Sent: Thursday, August 10, 2006 11:51 AM
Subject: Re: [ietf-dkim] Lean vs. Fat 'requirements'

> of the things that are preventing that from happening.

-1.

Although you can deploy DKIM-BASE today, speaking for myself, which my
customer have faith in, I can not in good conscious add DKIM-BASE into our
product line without securing signing Practices and Expectation behaviors.

> that's even worse in terms of deployment.)

-1.

I prefer not to repeat the ills of the pasts, nor repeat this process in the
future.  We are very close to achieving something that is probably not going
to happen again in our active careers.

SSP is rather very simple to code, not very complex at all.

But again, you are able to deploy DKIM-BASE today.  It is pretty much
complete.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 12:18:55 -0400

----- Original Message -----
From: "Hector Santos" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>

> Knowing you don't sign, and one if found, is strong evidence
> of a policy failure.

Sorry Frank, I mis-read your statement. you said "relevant".  Sorry. Need
another cup of cafe. :-)

+1

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Aug 2006 11:48:25 -0700 (PDT)

> it is rare to encounter this, IMV.

Read my previous message. It maybe rare now but what you ended up
doing is moving 3rd party senders to where they would change From
and add their name into it as 1st address and move or put what 
would have been or was original From address as 2nd one, basically
they would be emulating current use of "Sender" (in fact they
would still use Sender as required by RFC2822 in cases of
multi-address From). I'm not saying its all bad, but its a
change to current email system practices.

BTW - In above scenario I'm actually more concerned with situations
where the intermediate party would >>CHANGE<< From header field -
same parties that currently add Sender. First of all I dont want
that happening to my emails no matter who they go through and
2nd it will break existing signature if it existed.

---

From: Jon Callas <[email-masked]>
Date: Thu, 10 Aug 2006 12:00:25 -0700

> If an item engenders real wg controversy, it is *not* included.

Minimalist good.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Aug 2006 12:08:57 -0700

On Aug 10, 2006, at 11:48 AM, william(at)elan.net wrote:
>> Maybe I won't even bother with such nonsense multi-address from  
>> lines, which probably is going to break along some down stream  
>> anyway.  In all honesty, it is rare to encounter this, IMV.
>
> they would be emulating current use of "Sender" (in fact they would  
> still use Sender as required by RFC2822 in cases of multi-address  
> From). I'm not saying its all bad, but its a change to current  
> email system practices.

Agreed.  This could be an expected outcome of a policy restriction  
placed upon the From address.

> that happening to my emails no matter who they go through and 2nd  
> it will break existing signature if it existed.

Depending upon how common are the restrictive policies that prohibit  
other sources for a First Party Address, expect the First Party  
Address may  actually become a party or First Party Address(es).  An  
original signature being broken will not matter.  It would be  
illogical for the entity making the change to not also sign the  
message.  Handling multiple From addresses may become part of the new  
landscape.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 12:28:19 -0700

>> > signature (without the 's') is found.

This was a typo on my part. The intent was only one first party
signature is necessary. Sorry 'bout that; corrected.

> valid signer is a valid signer.

I would assume that that counts as a "valid first party signature".

       Mike

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 23:23:54 +0200

Scott Kitterman wrote:

> For the munger/non-munger approach, how would then domain
> owner know if it's users sent to mungers or not?  I don't
> see how that's possible.

When I read this article I thought it's something like this:

"All my mails are normally signed by me.  But I participate
 in mailing lists, for mails from known lists my signature
 can be broken (invalid / removed / whatever)."

It's then up to the receiver to define "known lists" somehow.

A relaxed "I sign all", stronger than "sometimes", because
reasons for a broken / missing signature should be "obvious"
for receivers.  We've to ask Wayne if that's what he had in
mind.

> For I know I don't sign, is there a special action a receiver
> can take if they get a message with a signature

They can reject it as not plausible without checking.  Either
an error on the site of the sender, or an emergency, one of the
odd cases discussed in the "threats" RFC.

> (maybe claranet started signing and you missed the message)?

I'd hope they publish an SSP in that case, it's quite possible
that I missed this... :-)

> If not, do we need to include it?

So far I'd like this better than a "null" policy meaning only
"you found it, and it's empty".  Admittedly this smells a bit
like "URI squatting" / "opt-out".

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 10 Aug 2006 22:19:32 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Damon" <[email-masked]>

>> Damon wrote:
>>
>> The Protocol MUST NOT be required to be invoked if a valid
>> first party signature (without the 's') is found.

> signature is necessary. Sorry 'bout that; corrected.

I vote to remove this requirement #9 since its design implementation concept
and it conflicts with some of other reguirements such as:  #2, #3, #4 and #7
which all have a need to check SSP first scenario.

Examples:

"No Mail Expected"   signed or not signed, it failed an expectation.

"No Signing Expected", it should not matter if the mail was signed by whom,
it failed an expectation.

and so on.

The implemention can choose to look at the verification of first or decide
to do the SSP first.   As long as the combined results produces the same
outcome, it should not matter how it is done.

On the other hand, in my technical opinion, to be consistent and  in order
to statisfy  discovery requirements,  a  more efficient model is to so SSP
first, before verification is done.  So if anything,  the discovery
requirements should promote Practice and Expectation requirement that says:

         The PROTOCOL SHOULD consider to be invoked first before the
          need for signature verification is required.

But again, a design consideration so I vote to remove it since its really
more about telling the protocol designer how the steps should be done.
Unless of course, we agree that this ought to be done. :-)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Aug 2006 09:31:01 +0100

Hector,

>>> first party signature (without the 's') is found.
...
> outcome, it should not matter how it is done.

Those are not in conflict. As I read it the requirement states that
an SSP lookup MUST NOT be REQUIRED (== is OPTIONAL) when a valid
first party signature is present.

I guess rephrasing it as follows might make you happier:

    The Protocol MAY be invoked when a valid first party signature
    is present.

       [INFORMATIVE NOTE: The expectation is that most implementations
       will not (always) invoke the protocol in this case.]

IMO those are equivalent, so I don't mind which gets used. Maybe
others prefer one over the other or don't agree about equivalence?

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 11 Aug 2006 05:29:42 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> others prefer one over the other or don't agree about equivalence?

I read it as optional too, and that's how will use it for our design too
(SSP first)

[Quick Response]

Maybe we have two requirements here:

     The PROTOCOL MAY BE invoked prior to verification as
     a pre-requisite for requirement 2, 3, 4 and 7.

     The PROTOCOL IS NOT required to be invoked when a 1st party
     signature is detected.

My suggestion is to remove it and allowed the designers to decide how they
want to do it or maybe split it because I think its two different things.

[Optional Detail Response}

As it stands now, to me, it doesn't sound like it fits when you compare it
against the following requirements:

   2. The Protocol MUST be able to publish a Practice that
      the domain doesn't send mail.

   3. The Protocol MUST be able to publish a Practice that the
      domain's signing behavior is "DKIM Signing Complete"

   4. The Protocol MUST be able to publish an Expectation that a
      verifiable First Party DKIM Signature should be expected on
      receipt of a message.

   7. If the Discovery process would be shortened by publication of a
      "null" practice, the protocol SHOULD provide a mechanism to
      publish such a practice.

If you have no signature, then there is nothing to verify.

This seems to all say that maybe we need a nemesis of "DKIM Signing
Complete"  called "DKIM Verifier Complete"  <g>

So it seems to me that you have 4 out of 10 requirements, that conflicts
with the "MUST NOT be required to be invoked" requirement because in order
to satisfy 4 of them, you need to do a lookup to handle the cases where
there is no signature in the message.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 11 Aug 2006 09:03:07 -0400 (EDT)

> others prefer one over the other or don't agree about equivalence?

I prefer the "must not be required" form. I know that it implies
"may perform SSP lookup", but the latter form can more easily be
lobbied into a stronger recommendation for SSP lookup, which is
definitely not what I want.

	Wietse

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 09:43:52 -0400

Hector,
The issue with checking SSP first is that DKIM base is stand alone. Some
people will deploy base and not deploy SSP until much later if at all.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Thursday, August 10, 2006 10:20 PM
To: Michael Thomas; Damon
Cc: [email-masked]
Subject: Re: [ietf-dkim] Issue: Requirements #9 NOT REQUIRED for
1stpartyvalid signatures.

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Damon" <[email-masked]>

> signature is necessary. Sorry 'bout that; corrected.

I vote to remove this requirement #9 since its design implementation
concept
and it conflicts with some of other reguirements such as:  #2, #3, #4
and #7
which all have a need to check SSP first scenario.

Examples:

"No Signing Expected", it should not matter if the mail was signed by
whom,
it failed an expectation.

and so on.

The implemention can choose to look at the verification of first or
decide
to do the SSP first.   As long as the combined results produces the same
outcome, it should not matter how it is done.

On the other hand, in my technical opinion, to be consistent and  in
order
to statisfy  discovery requirements,  a  more efficient model is to so
SSP
first, before verification is done.  So if anything,  the discovery
requirements should promote Practice and Expectation requirement that
says:

But again, a design consideration so I vote to remove it since its
really
more about telling the protocol designer how the steps should be done.
Unless of course, we agree that this ought to be done. :-)

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 11 Aug 2006 11:05:09 -0400

----- Original Message ----- 
From: <[email-masked]>
Sent: Friday, August 11, 2006 9:43 AM

> Hector,
> The issue with checking SSP first is that DKIM base is 
> stand alone. Some people will deploy base and not deploy 
> SSP until much later if at all.
> Thanks,

I don't see any logic in that but thats ok.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 11 Aug 2006 11:54:11 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>

> definitely not what I want.

I am curious to know, from an engineering standpoint,  why it is something
you definitely not want to see implemented?  What am I missing here?

While I prefer the latter because I believe it is better design, it really
doesn't matter to me what it says or not since its an implementation issue.
May the better implementation win.

But if there is a fault in my proposal, I would seriously like to have the
feedback if you may.  If I'm wrong, Great! Just like to know what's wrong
with doing SSP first as implied by requirements 2, 3, 4 and 7, but
inconsistent with requirement 9?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Aug 2006 10:05:28 -0700

On Aug 11, 2006, at 1:31 AM, Stephen Farrell wrote:

> Hector Santos wrote:
>
>>>> The Protocol MUST NOT be required to be invoked if a valid first  
>>>> party signature (without the 's') is found.
> ...
>> The implemention can choose to look at the verification of first  
>> or decide to do the SSP first.   As long as the combined results  
>> produces the same outcome, it should not matter how it is done.
>

FPA = First Party Address
FPD = First Party Address Domain
FPS = First Party Signature

Clarify the definition of FPS and FPD.

This should be considered for the following reasons:

- Delegating domains or exchanging key/selectors on a large scale is  
not practical.

- DKIM signatures, in combination with policy that lists domains  
authoritative for a FPD, provide a practical means to confirm the  
validity of the FPA.  A policy listing authoritative domains allows  
the FPA to be validated while the signing domain is outside the FPD.   
FPA validation and appropriate annotations of a validated FPA  
recognized and applied by an MUA, in conjunction with correspondence  
or address book information, represents a protection scheme immune to  
internationalization and look-alike exploits often used in phishing  
gambits.  This protection scheme does not require support by outside  
services to be effective.

- The protection using FPA validation does not require policy to  
disqualify message sources.  A list of authoritative domains must be  
considered to be separate of any assertion of exclusivity of  
sources.  This separability is a policy requirement.  With this  
separability and the FPA validation protective mode, other common  
email services, such as mailing lists, are not impaired.

- An organization like the DAC, might certify which DKIM providers  
adequately protect FPAs when the signing domain is not within the FPD.

- A policy listing authoritative domains can utilize wildcards as a  
means to indicate whether subdomains are authoritative.

- A policy listing authoritative domains can also exclude a parent  
domain as being authoritative.

This last point requires a clarification in the definition of FPS and  
PFD.  Not defining a parent domain as matching by default with that  
of the authoritative list of domains will return some control to the  
domain owner.  The domain owner would not be fully dependent upon the  
parent domain to limit their exposure to many types of breaches that  
may occur within the parent domain.  Excluding a parent domain match  
as a reason for not obtaining policy would therefore improve security.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Fri, 11 Aug 2006 16:10:38 -0400 (EDT)

> you definitely not want to see implemented?  What am I missing here?

At this stage we are talking about a minimum protocol. You are free
to implement SSP lookups that exceed the minimum protocol. However,
I would oppose recommending SSP lookup in a particularly important
scenario where now such lookup "must not be required".

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 12 Aug 2006 07:46:01 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>

> scenario where now such lookup "must not be required".

Wietse,

Yes, I think we established implementators lead independent lives and in the
end we will provide the local policy options for administrators to use.  :-)

But for that reason, I would still like to extract why one implementator
such as your astute person as yourself, opposes it from an engineering
standpoint?

Is it because the valid 1st party signature is well established as
sufficient to create high reliability in the result without needing a policy
confirmation?  An optimization consideration?

Maybe we are just talking about adding an informative note?

    [INFORMATIVE NOTE: Valid 1st party signatures satisfies the
     DKIM-BASE requirements for an authenticated and authorized
     message from the domain.]

Don't get me wrong, I understood the document. But the design now seems to
be predetermine as it is stated.  When a modeler sees the finished minimal
requirements document, one minimal model can be outlined as:

  if first party signature found then
      if successful Validataton() then
          return CLASSIFY_AS_PASS

  if failed Policy()  then
      return CLASSIFY_AS_FAIL

  if successful Validataton() then
     return CLASSIFY_AS_PASS

  return CLASSIFY_AS_FAIL

Do you agree with such a model fits the minimal requirements?

The problem?

It now goes back to the debate of "Exclusivity" or the present of a 3rd
party signature valid or not is allowed.  I believe the provisional
requirement #5 (delegation) attempts to address this minimal optional need.

In such as case, the minimal model can be:

  if failed Policy()  then
      return CLASSIFY_AS_FAIL

  if successful Validataton() then
     return CLASSIFY_AS_PASS

  return CLASSIFY_AS_FAIL

---

From: [email-masked] (Wietse Venema)
Date: Sat, 12 Aug 2006 10:23:45 -0400 (EDT)

> such as your astute person as yourself, opposes it from an engineering

Sorry, I think that I have made and clarified my point sufficiently,
and that further discussion will not produce new insights that are
relevant for the charter of this list.

	Wietse