Subject: [ietf-dkim] How to reconcile passive vs active?

From: Mark Delany <[email-masked]>
Date: Mon, 7 Aug 2006 04:20:38 +0000

> From: "Dave Crocker" <[email-masked]>

> why is is not sufficient to leave things with the simpler -- albeit
> more passive -- stance that a sender talks about themselves but
> refrains from telling the evaluator what to do with the information?
> Yes, that is at odds with a classic model of protocol specification,
> but we are juggling among constraints, here.

As one of the chairs pointed out, we are probably circling at this
stage and are consequentially not covering much new ground. (I quote
Dave solely because he encapsulates the differences succinctly).

It obvious that there are two relatively strong viewpoints: one the
passive that Dave describes and one the active that, amongst others, I
describe.

If we take the high ground and accept that both viewpoints are valid
then our job is no longer to argue our differences, rather it's to
work out how we accommodate those differences.

So how do we do that? Do we try and settle on one perspective?  My
guess is that that seems unlikely.

Do we try and accommodate both? If so, how?

Or, is this mostly a matter of semantics with the end result being
pretty much the same SSP syntax, but a different set of semantics in
the specification? If so, can we work on the syntax and defer on the
semantics as a means of moving forward?

If it's agreeable to others, I'd like to suggest that as a way of
moving forward, we focus on the meta-issue of how we resolve this
difference rather than focusing on the details of the difference.

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 06 Aug 2006 21:44:09 -0700

> difference rather than focusing on the details of the difference.

1. I suspect the syntax is the same, and certainly suspect we need not focus on
possible differences.

2. I think that the passive/active difference involves a superset/subset
relationship.  That is, I think that the active begins with the statements made
in the passive mode, about the sender/signer, but extends them to tell the
evaluator how to use those statements.

3. If #2 is correct, then my question is why the extended semantics are
essential?  What problems are created by not including them in the
specification?  What substantial benefits are obtained by including them?

d/
-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Sun, 06 Aug 2006 22:06:40 -0700

>specification?  What substantial benefits are obtained by including them?
The one downside is that there seems to be a serious amount of confusion
about what people think receivers will do with this information, and the
SPF experience is not encouraging. At the very least even if the protocol
doesn't try to falsely dictate what a receiver must do, it should at 
least warn
unsuspecting deployers that if they don't understand exactly what the
extremely narrow use scenario SSP is then they'd be crazy to set it. I
don't think it's really sunk in as to how small the set of senders who 
will find
this useful is, or how disruptive it will be if you accidentally set it 
when it
doesn't apply to you.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 7 Aug 2006 01:27:14 -0400

> guess is that that seems unlikely.
I think we have to try and agree on what we mean.  If we don't and punt it to 
the individual implementers to figure out what the WG meant, then it will be 
confusing both for the implementers and domain owners trying to decide what 
to publish.

> Do we try and accommodate both? If so, how?
I think we have to find a happy medium that everyone can at least live with.  
I don't know if we'll succeed, but we ought to at least try.

> semantics as a means of moving forward?
I think it has some potential to impact the syntax.  

As I mentioned in a note I sent shortly before going on vacation last week, 
some domains will come at DKIM with or without SSP with the view that they 
want to highlight the positive messages that carry their identity and 
increase deliverability for those.  Others domains will come to the protocol 
interested in making it easier/more reliable for others to determine which 
messages pretending to be from them they did not send.

If "I sign everything" means that and nothing more, then that is all the 
complexity that is needed.  If it means "I sign everything and despite the 
fact that stuff will get broken en route to the receiver, I [expect/require] 
the messages that don't validate not be delivered" then it might need to be 
more complex.  While that might work for the second group above, the first 
probably wouldn't want to do that.  So something in the syntax might be 
needed to signal the sender [expectation/requirement].  For those familiar 
with SPF, it would be the difference between ending a record with ?all 
or -all.
> difference rather than focusing on the details of the difference.
I think there is also a third middle ground view (to which I subscribe) that 
while we shouldn't specify (e.g. the receiver MUST...) receiver policy, we 
should describe how the sender expects/hopes the receiver will deal with 
messages that do/don't verify.

By how we resolve this difference, I assume you have something in mind other 
than spending another week sending 100 e-mails a day to the list?  

I'd suggest that the chairs pick someone with either no strong position on the 
matter or a middle ground position to attempt to draft a consensus statement 
and then let both sides pick on it and see if we get close to a rough 
consensus.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 01:38:54 -0400

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

> about what people think receivers will do with this information,

Might I suggest using the term "differences of opinion or positions" rather
than confusion.  I am not confused at all about it.

> and the SPF experience is not encouraging.

Michael, the SPF experience was highlighted due to the RELAXED provisions
that that SSP proponents are trying to avoid in DKIM/SSP.  This is the
exactly the reason why SSP must also support strong policies.    Ironically,
the  SSP opponents are modeling a "NEUTRAL"  DKIM-BASE system which is
exactly whats causes problems.   In  SPF, the HARD policies increases
problems with Forwarding isses.   We don't have that problem with DKIM/SSP.
That is the beauty and attraction of DKIM/SSP.   It offers the highly
desirable strong policies that are problematic but also desirable in SPF.

> At the very least even if the protocol doesn't try to falsely dictate
> what a receiver must do, it should at  least warn unsuspecting
> deployers that if they don't understand exactly what the extremely
> narrow use scenario SSP is then they'd be crazy to set it.
> I  don't think it's really sunk in as to how small the set of senders who
> will find this useful is, or how disruptive it will be if you accidentally
set it
> when it doesn't apply to you.

I don't quite agree with your presumption it will be extremely narrow use,
but we always said Local Policy Decisions always trumps whats anyone sends
to you.

Even then,  the main issue are the potential damages that are being ignored.
My wife said it best when asked why even the BIG companies like WALMART,
YAHOO, CISCO,  AOL.COM,  BIGBANK should also support strong policies:

   "Why not? They should always check because it is the
    little guy that will pay the price anyway. If the big
    guys is going to allow the little things go by, the crooks
    will also try to do the little things to the little companies
    where $20 means something to them!"

And thats is exactly  what I am worry about, exactly.   A great majority of
my junk is coming from  messages that have "high value" domain names.

Once a DKIM-BASE  non-SSP or very watered down version becomes widely
adopted,    maybe the new fee based reputation-based social networks will
prosper without SSP, but it will be the rest of the world , the great
majority that is mostly the "small guys" who will have to deal with the DKIM
junk that is coming their way.

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

---

From: Michael Thomas <[email-masked]>
Date: Sun, 06 Aug 2006 22:53:21 -0700

>YAHOO, CISCO,  AOL.COM,  BIGBANK should also support strong policies:
I can say with little hesitation that Cisco will never publish the "strong"
policy as envisioned by Mark for our user population. I'd be interested
to hear from Mark whether Yahoo-inc ever would for their corporate
users.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 02:16:19 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, August 07, 2006 1:53 AM
Subject: Re: [ietf-dkim] How to reconcile passive vs active?

> to hear from Mark whether Yahoo-inc ever would for their corporate

I agree 100% with you that most likely the larger big companies broadcasting
mail to outside would may not have strong policies.   (But will your
customers who are using Cisco Products wish to have the option to use of
strong policies?)

Unfortunately, this is exactly what I am afraid of. This is exactly what the
bad guy would hope as well.

That's the problem.

Figurely speaking, there are only a "handful" of big companies, there are
hundreds of thousands if not millions of smaller companies which make up the
majority of the internet.

The big companies of the world, using relaxed signature policies or
basically as DKIM-BASE only system, made to only work with augmented
reputation systems, the bad guys will use this DKIM-BASE only concept
against everyone else, the majority of the world which is made of the
smaller systems.

My wife, the lay person, the "Everyday" person, a user of these products,
said it best.  If the "CISCOS" are going to allow the low cost issues go by,
it will be the little guy will be feel the blunt of these low cost issues
which matters to them.

The other side is this?

Will you support the checking of policies for fraudulent mail coming into
CISCO?

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 6 Aug 2006 23:42:52 -0700 (PDT)

On Sun, 6 Aug 2006, Michael Thomas wrote:

> I can say with little hesitation that Cisco will never publish the
> "strong" policy as envisioned by Mark for our user population. I

But what makes you think you should be the one to decide for everyone
what their policies is and if they should or should not be allowed to
publish strong policy?

The requirement for your document is clearly that not everyone is
the same and so that should be reflected in policy syntax allowing
for more choices then just "I sign all: yes/no". And BTW, DSAP has
this covered quite well with its multiple failure handling tags
so you can adjust policy to fit to your situation.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Mon, 7 Aug 2006 06:48:32 +0000

> to hear from Mark whether Yahoo-inc ever would for their corporate

The question is whether there is a useful subset of domains that want
a "strong" policy.

All indications on this list are that a good number of us think "yes",
so the "strong" policy position needs comprehensive coverage in your
requirements I-D. Have you got that covered in your draft or would
additional text be of use to you?

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 03:10:11 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>

> ...

In my opinion,  and I had asked the chair a  week or so to consider this
approach:

I also proposed a straw vote on the fundamental question:

       Do you believe there are security problems
      directly or indirectly related to DKIM-BASE  that are worth
      solving or addressing using a Sender Signer Policy concept?

If we can't get this one clear, then you are right, there is essentially no
hope in solving this.  If the censensus is such the answer is NO, then we
punt on SSP, WG is basically done.

If the answer is YES, then we need to itemized the security problems we need
to address related to DKIM-BASE signatures or lack thereof.  Once this
secury list is established, then we can come up with policy declarations
that help address them.

But there is no need to do anything else of the consensus there is no
security problems with DKIM-BASE.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Aug 2006 12:21:02 +0100

Mark Delany wrote:
> requirements I-D. 

Chair-ish quibble: I think the positions exposed on the list must of
course be covered in reqs-00, but I also think the more words that
are used to do that, the more disagreement we'll get. Put another way,
I hope no-one wants to see a reqs-00 that has near as many words as
have been posted to this list over the last couple of weeks.

So s/comprehensive/adequate/ above seems better. I really hope Mike's
draft is short and sweet, though that's a pretty tough challenge for
him,

S.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 09:03:29 -0400

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

> Chair-ish quibble: I think the positions exposed on the list
> must of course be covered in reqs-00, but I also think the
> more words that are used to do that, the more disagreement we'll
> get. Put another way,  I hope no-one wants to see a reqs-00
> that has near as many words as have been posted to this list
> over the last couple of weeks.

+1,

I'll be happy with just a fascimile of the following block of words:

 - Protocol must offer support for the following domain
   policies:

    - no mail ever expected by domain
    - no signature expected whatsoever by domain
    - domain signature optional, no third party expected
    - domain signature optional, 3rd party allowed. See below.
    - domain signature required, 3rd party allowed. See below.
    - domain signature required, no 3rd party expected

 - Protocol must support optional "allow list" of domain allowed
   to sign.

Bonus Block of Words:

 - Protocol must offer optional "Highest Hashing Method
   Possible" understood by target end point.

Maybe MT can just cut and paste this small block of words in and I think
reached pareto's ratio! <g>

---

From: [email-masked] (Wietse Venema)
Date: Mon, 7 Aug 2006 09:23:19 -0400 (EDT)

Hector Santos:
[ Charset UTF-8 unsupported, converting... ]
>       solving or addressing using a Sender Signer Policy concept?

None. If a message is signed by example.com, then that signature
introduces no security vulnerability, even if the message originates
from some other, unrelated, domain.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Mon, 07 Aug 2006 07:38:34 -0700

> draft is short and sweet, though that's a pretty tough challenge for

In fact the actual policy itself better be able to be reduced to a single
comprehensible sound bite or I think it's likely that we haven't done
our job -- if we can't state it concisely, how can we expect people
to understand hearing it for the first time whether it's something
they can use or not?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 07 Aug 2006 07:35:41 -0700

>The question is whether there is a useful subset of domains that want
I take that as a "no". Does it not bother you that there are a lot of 
people who
are confused about why adopting such a policy in the incorrect situation 
would
be harmful? As stated, your policy does not capture the correct 
pre-conditions
of when somebody might usefully publish it.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Aug 2006 09:05:53 -0700

> All indications on this list are that a good number of us think "yes",

That's helpful, but probably not enough.

We still need to understand why such specification is essential to the
specification and why we believe it will work.

d/

-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 12:56:59 -0400

----- Original Message -----

> specification and why we believe it will work.

Dave,  in my opinion,  every aspect has been discussed, debated, outlined,
chewed in and out, tattooed  in the forms of WG discussions over the last
16-20 so months, with illustrations and I-D documents created, including the
following drafts:

http://tools.ietf.org/wg/dkim/draft-ietf-dkim-base
http://tools.ietf.org/id/draft-allman-dkim-ssp-01.txt
http://tools.ietf.org/wg/dkim/draft-fenton-dkim-threats-02.txt
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt

All these documents touches base with policy issues with the DSAP draft
outlining the issues in more detail.

With all this wealth of information together, it should be ample material to
take a few moment of your time to better see the concerns and proposed needs
for policy, including strong policies.  But clearly, applying various
terminologies and semantics out of the blue is not going help extract what
is being sought by you.  Passive vs. Active?

And in my opinion, It will be fascinating to see how a technical
requirements
draft can be well written with enough insight by anyone who doesn't
understand, does not have faith nor believe in what he or she is creating.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 7 Aug 2006 13:17:42 -0400

On Monday 07 August 2006 03:10, Hector Santos wrote:
> If the answer is YES, then we need to itemized the security problems we
> need to address related to DKIM-BASE signatures or lack thereof.  Once this
I would describe it differently.  It's not that base has security problems, 
it's that it fails to accomplish anything with significant utility.

We'll see how much utility we can get out of SSP, but absent some additional 
functionality (be it SSP or non-standardized reputation systems) base doesn't 
get you much in my opinion, but...

This is all rehash of the discussion we had about the charter before the WG 
was formed.  In my view the SSP/no SSP decision was made.  Now the challenge 
is to see what we can make of it.

Scott K

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 07 Aug 2006 12:31:14 -0500

> I don't think it's really sunk in as to how small the set of senders
 > who will find this useful is, or how disruptive it will be if you
 > accidentally set it when it doesn't apply to you.

 From my perspective, the number needn't be small at all.  Small 
organizations with their own mail processing infrastructure can with 
relative ease audit their servers and outbound flow thus making an o=! 
policy decision with more confidence and in less time than, say, a Bank 
of America could.  Coupled with an inherent desire to protect what is, 
even for small business, a core corporate asset, o=! would seem to me to 
be a welcome option.

-- 
Arvel

---

From: Steve Atkins <[email-masked]>
Date: Mon, 7 Aug 2006 10:46:15 -0700

On Aug 7, 2006, at 10:31 AM, Arvel Hathcock wrote:

> organizations with their own mail processing infrastructure can  
> with relative ease audit their servers and outbound flow thus  
> making an o=! policy decision with more confidence and in less time  
> than, say, a Bank of America could.  Coupled with an inherent  
> desire to protect what is, even for small business, a core  
> corporate asset, o=! would seem to me to be a welcome option.

Even when it decreases overall deliverability? That is to say, causes  
legitimate email to be treated as forgeries and, likely, discarded.

I can see cases where that's going to be an appropriate tradeoff, but  
I don't think they're as widespread as some people think.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Aug 2006 11:10:03 -0700

...
> I can see cases where that's going to be an appropriate tradeoff, but I
> don't think they're as widespread as some people think.

We need to find a way to discuss the design choices so that we are not faced
with a bevy of personal prognostications about the likelihood of particular
outcomes.  Most, if not all, of us will be wrong.

Rather:

Do we see a clear and compelling benefit for a design choice being proposed?

Is it substantially better than some other choice being proposed?

Do we see an absence of significant detriments? (Complexity, scaling,
performance, reliability, etc.)

Do we see a clear and substantial base of users/organizations for the choice NOW?

Only then might we consider adding a guess about the size of the population from
which this sample of adopting users/organization is taken.

Debating whether my sample is bigger than yours is certain to be unproductive.

d/
-- 

  Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 7 Aug 2006 11:39:00 -0700

> Debating whether my sample is bigger than yours is certain to be  

Definitely.

A lot of the controversy about SSP is based on
false positives - mail that was signed when sent but is not
signed when received.

I know that various people have been looking at the cases where
that can happen, but I don't recall seeing any quantitative
results presented. If they have been, could someone point me
at them?

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Aug 2006 11:57:55 -0700

> results presented. If they have been, could someone point me

I wonder whether this issue might be amenable to resolution without worrying
about empirical statistics.

In other words: Perhaps one or all SSP settings require non-breakage along the
path.  If there is breakage, the mechanism is effectively disabled.

In other words:  Exactly how bad is it, for a legitimately signed message to
fail the signature check and then be subjected to the usual vagaries of filter
analysis?

Similarly:  Exactly how bad is it for an SSP I-Sign-All domain to have an
unsigned message succeed through filters and get delivered?  (I am tossing this
into the mix, from the exchange Delany and I are having, about dictating
delivery behavior.)

I keep thinking that the fatal flaw to much of these discussions is our concern
for perfect performance, rather than accepting that we won't get it and trying
to make sure that errors are acceptable.

d/
-- 

  Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 07 Aug 2006 12:04:30 -0700

> results presented. If they have been, could someone point me

It's not just quantitative, but qualitative. Quantitatively, we're seeing
about 2% breakage through lists or so. Qualitatively, there's nothing
that we can do to make that zero, and as a given user through a
given piece of list software, the quantity may be 100% (Y! groups
seems to be one of those). Will these cause cases to be opened with
IT? Sure seems like it to me. Do IT folks like new cases opened for
acceptable behavior? Not that I've ever seen, especially when they
don't have a way to resolve it.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 15:27:49 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: "DKIM List" <[email-masked]>

> legitimate email to be treated as forgeries and, likely, discarded.

The fraudulent mail covered are for 0% FALSE POSTIVES. Absolutely No FUZZY
LOGIC. If it was fuzzy, I personally wouldn't wasting my time anymore here.

> I don't think they're as widespread as some people think.

The last time someone doubted the potential for fraudulent mail:

   From RFC 2821

   7.1 Mail Security and Spoofing

   ...

   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.

that "ignorant user" turned into a world-wide multi-billion industry
powerhouse.

The SSP is about the 100% detection with 0% false positive of the most
obvious of fraudulent mail, the ones that the unprotected DKIM-BASE protocol
leaves hanging in the wind to be easily exploited.

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 15:34:53 -0400

Here is the scenario:

My CEO calls me and says, "I sent an email to the SEC and they never got it!"
- I tell him to hang on whilst I check the logs (and I finish my bagel)
... "We are showing a successful delivery. I will get hold of the
postmaster at the SEC an figure it out."
So I spend half a day trying to get the right schmuck on the phone and
another half a day trying to convey the urgency. (Like he/she cares
right?)
I call back my CEO who is pacing his office rug...
"Sir, it seems that they deleted our email because our sig was munged
and we have a 'I Sign All' policy"
"WHO told you to put in that policy?!" he pants.
"You did sir. Remember last year... you saw it in NetworkingWorld and
thought it was a good idea" - quickly reading off my CYA notecards.
"Well how do we FIX it?!" - My CEO now thinking I am a <editted> and
tossing my SVP paperwork in the circular file.
"We turn it off sir." Hearing the shredder and knowing in my gut what
he is shredding.
"DO IT (you ...... indistinguishable muttering)"
"Yes sir, but please be advised that we have our TTL's set kinda
longish.. it will be at least a day"
"... more indistinguishable muttering.. *click*"

- several months go by -

"Sir, my SVP wants to turn 'I sign all' back on. but I don't think we should."
- Suddenly my SVP paperwork is back on the desk and my VP is sorting
*real* mail.

I don't want this to happen to me.
Also, the first time it happens will likely be the last too.

I will concede that the strong "I sign all" is ok for transactional
message coming from the guys that get phished all the time... but I
would like to continue looking at something smaller than the nuclear
option.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Aug 2006 13:08:09 -0700

On Aug 7, 2006, at 12:27 PM, Hector Santos wrote:
>> Even when it decreases overall deliverability? That is to say,  
>> causes legitimate email to be treated as forgeries and, likely,  
>> discarded.
>
> The fraudulent mail covered are for 0% FALSE POSTIVES. Absolutely  
> No FUZZY LOGIC. If it was fuzzy, I personally wouldn't wasting my  
> time anymore here.

When a domain signs all of their outbound messages and makes a  
statement as such, there are still common services that might be  
employed.  Strict adherence to an expectation of a message always  
having a policy conformant signature where policy does not permit an  
exception for these services will cause those services to be rejected  
or discarded.  Many would view such rejection as representing a false  
positive, when the message was legitimately issued on behalf of the  
 From domain.

An option is needed to indicate whether other messages without valid  
signatures might be from valid sources acting on behalf of domain  
issuing the policy.  Dealing with email that allows this exception  
will be less black and white.  An expectation that all messages must  
be signed by designated domains will not supplant the need to handle  
abusive messages from bad actors, and at the same time will increase  
the number of support calls.

-Doug

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 18:07:27 -0400

-----Original Message-----
From: [email-masked] on behalf of Damon
Sent: Mon 8/7/2006 3:34 PM
To: Michael Thomas
Cc: DKIM List
Subject: Re: [ietf-dkim] How to reconcile passive vs active?
 
Here is the scenario:

My CEO calls me and says, "I sent an email to the SEC and they never got it!"
"was it important?"
YES!
"then you should have sent it overnight return receipt requested via US mail, email is for non critical communications"
I thought electronic communications is the future!
"Well EDS, WLNP, WLP and other methods are indeed, email is not"
WHY NOT!
the infrastructure is there but the Policy of messaging exchange is not"
By the way did you sign the request for the autogyro megapipe?
"What the heck is THAT?"
I need it for the automated biradial contact device Im experimenting with
mumble......

- several months go by -

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 04:19:03 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> No FUZZY LOGIC. If it was fuzzy, I personally wouldn't be wasting
>> my time anymore here.

> positive, when the message was legitimately issued on behalf of the

No doubt. I agree.

But this is an implementation issue.  That is why it is all optional, a
tradeoff, migration issue, security issue, a company decision to balance
exactly who/how thier domain properties are to be used.

But it still about a domain declaring a policy that is to be interpreted
with 0% false positive and no fuzzy interpretations in mind.  DKIM-BASE is
already fuzzy enough with its "ignore failure as it was never signed"
concept.

With SSP, we are diluting some of the DKIM-BASE fuzziness:

  DKIM-BASE-FUZZY + SSP-NO-FUZZY  =  DKIM-BASE-LESS-FUZZY

With SSP, all fuzziness remains with the purity of the DKIM-BASE
verification process of the signature.  At this point, we won't be
questioning the authorization or usage aspects of the signature, but rather
authenticity.

Its about removing the obvious abuse, no more, no less.  The SSP policy
considerations I have in mind are before the DKIM signature verification
take places.

> issuing the policy.

Ok, it is produces 0% FALSE POSITIVE Policy concept. I'm fine with that.

But with what we have now with all the work done with SSP, including my own
work with DSAP, its about removing the obvious abuse.

Review the verification flow chart outlined in DSAP.

or better review this earlier chart with the SSP model:

http://isdg.net/public/ssp/ssp.htm

You will see that the obvious policy abuses are quickly disseminated.  These
are 0% FALSE POSITIVE considerations.

This is really the same concept and debate regarding the DKIM-BASE
Expiration Tag.

      Do you really need to do a signature hash verification
      when the x= tag has an expired date?

No, not from my viewpoint. That's overhead.

The x= debate goes lost with key management debates. But conceptually, it is
really the same kind of dispute. An Expire tag is an really a Policy
concept.