Subject: [ietf-dkim] draft-ietf-dkim-ssp-requirements-00.txt available

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Aug 2006 10:11:35 -0700

at:
http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-00.txt

until it shows up in the draft repository. Full disclaimer, this has been
put together in a very small amount of time, sifting through a huge amount
of mail on the list.

       Mike

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 18:46:04 +0100

I'd like to thank Mike for putting this together while the list
traffic was speeding by at such a rate.

When commenting on this, the usual approach applies of course,
in that its much better to suggest alternate text where you'd
like it to say something else. Try if you can to keep that at
the level of specific requirements, and e.g. don't send an
entire new I-D as you alternate text.

And it is still a good idea to avoid repeating oneself, (he
said yet again:-), which is another reason to prefer comments
supplying alternate text.

Thanks,
Stephen.

---

From: <[email-masked]>
Date: Tue, 8 Aug 2006 14:30:54 -0400

I like the acknowledgement section

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 Stephen Farrell
Sent: Tuesday, August 08, 2006 1:46 PM
To: Michael Thomas
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-requirements-00.txt
available

Thanks,
Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 20:13:49 -0400

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

> until it shows up in the draft repository. Full disclaimer, this has
> been put together in a very small amount of time, sifting through
> a huge amount of mail on the list.

Michael,

I reviewed it. Great work.  I can personally appreciate the effort you put
into it.  Thanks!  Before this gets lost in any of comments below, I wish to
take this opportunity to publically apologize to you for being impatience
and for any rudeness shown by me. Sorry.

As one "Author of Software," I have a small checklist of functional design
requirements that needs to be satisfied. I put a check on the ones reg-00
has directly or indirectly addresses or touches base with.

Required Functional Support Items:

 [X] No Mail expected domain policy
 [?] No Signature expected domain policy
 [X] 1st party signature expected domain policy
 [X] Exclusive Signature domain policy
 [X] 3rd party signature allowed domain policy
     [_] 3rd party Strip/Replace domain policy
 [X] Allow Domain Signer list

Optional Functional Support Items:

 [X] Highest Hashing Method Available domain attribute

Overall, I think it covers most of everything.

The 3rd party strip/replace has to do more with Middle Ware issues.  The
question is whether we provide some functional guidelines for Middle Ware
authors to help become more "DKIM-Friendly" to help with the survivability
of the message?   This is also related to #9 item as I discussed below in my
2) Chicken vs. Egg comment.

Specific comments:

1) Null Practice

A "null" practice is not clearly defined. It is first used or introduced as
it was already defined.

 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.

We need a hard core declaration that either a signature is expected or not
expected.   This is different from being "neutral", the idea that is a
widespread consensus that relaxed policies create unstable states, it is
still a concept that still needs to be allowed to be defined for increase
the acceptability and adoption of DKIM-BASE, i.e. a migration concept.

>From an implementations standpoint, it comes down to a matter of saying that
if there is a signature present with a NEUTRAL policy present,then it better
be valid (higher score for failure).  But if there isn't a signature, then
the implementation will simply punt and move the email to the next stage if
any.

The only harm here is the DOMAIN itself. He is the one flirting with danger
when verifiers see that a NEUTRAL policy is always failure in the DKIM
signature verification process.  Understand?

I vote to keep the idea, but if removed, I will not argue against it. It
just puts more strain in the adoptability area. i.e, forcing organizations
to decide a lot quicker  which probably ok by me.

2) Chicken vs. Egg problem

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

This #9 item has no reason to exist. As long as the end results are the
same, there is no need to dictate how an implementation is done.

I vote to remove it.  It has no relationship to what you are trying to do
here with "functional" requirements.  What if my implementation is such that
it does invoke the protocol at all times before the verification process
begins?  Am I now in violation of the standard SSP protocol?    No. As long
as the same end results are achieved, it shouldn't matter.   But in my case,
it is done in a more optimal and more efficient matter.

Look at it this way, change it to:

   9.   The Protocol MUST allow to be invoked before the verification
        process takes place.

You see?  This also dictates design implementation too.  The end result is
really the same, but one can argue (meaninglessly) that allowing an
invocation of the protocol before a verification is done is more efficient.

So I vote to remote this one.

Overall Mike,  Great job!

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

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 21:17:13 -0400

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

I would like to changed my vote to remove this requirement.

I still think it is independent concept, but I would suggest that the
semantics be changed or keep as is but with some additional hindsight as to
why it might be useful.

Suggestion (just an example, I won't quibble with wordsmithing)

     [INFORMATIONAL NOTE:]

     There are policies that can be satisfied by the DKIM-verifier
     prior to any verification of signatures is required.
     Some implementations might find this design is more
     efficient and offers scalability considerations.

---

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

I've finished my first cut at comments and I'd like to add my thanks to Mike 
for putting together such a good draft in such a short amount of time.

Scott K