Hi everybody,
I'd be very, very grateful for such a semi-detailed summary!
Julian.
Oh where do I begin :-) Well, I have been smack in the middle of it, seems
like as Arvel (altn.com) says "I'm the champion for SSP."
If you want a quick soap opera catchup here goes. I will admit my faults
here too.
I was concerned when SSP was ripped about from DKIM and always felt it was a
mistake. But for the same of progress I step back from DKIM-BASE
discussions and it was amazing to see how fast it got done :-)
I had already raise my concerns and I got most if not all mentioned in some
form or another. Overall, there are 1-2 major concerns with DKIM-BASE:
"Ignore Failures, Treat as if never signed"
"Only 1 valid signature is required, even if other fails"
I felt and still do this makes DKIM-BASE an unprotected protocol.
Issues regarding c14n (canonicalization) came up regarding UNIX vs DOS vs
MAC CL/LF differences so I wrote up a I-D that basically strippes all
control codes, but added a new hash of the original content which was the
problem with older but similar NOFWS that also strips all CR/LF (except for
last, if I remember) and you use security. The new hash help bring back
the security.
That was it for DKIM-BASE.
In anticipation of SSP talks, I put together a PowerPoint presentation of
the security problems of DKIM-BASE protocol with ideas to help address them.
DKIM Signature Authorization Protocol:
Power point presentation (in PDF)
http://isdg.net/public/ssp/dsap.pdf
I was encouraged by the chair and others to write a I-D and attend the
Montreal IETF July meeting, but scheduling conflicts did not allow this to
happen. But I continued with the work and believed it was too important
to let it die. I felt if I wrote it up as a security document than it will
get ears and eyes. But even the chair felt if I used the word "unprotected"
it will pist off people. I wrote 2-3 drafts on this, wordsmithing it so
that it didnt sting that much.
DKIM Signature Authorization Protocol:
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html (HTML
version)
My goal was not to replace SSP but to to use DSAP to highlight the issues
and if they wanted to chop it up and pull ideas out, GREAT - job done!
William Elan, Scott Kitterman, Tony Hansen, Bill Oaxley and a few others
help. William helped alot. It was going to be my first big IETF draft so
I did a practice one with:
Partial DKIM Verifier Support using a DKIM-Received Trace Header
http://tools.ietf.org/wg/dkim/draft-santos-dkim-rcvd-00.txt
I think DSAP provided a pretty good overview of the DKIM security problems
and illustrates the theortical boundary conditions for possible policies to
help resolve them.
The most important "add-on" by DSAP was::
- Having a REAL Exclusive Policy, "I always sign and no one else"
- Defining a "allow list" of authorized 3rd party signers,
- Definine the highest hashing method possible.
- Verifier Policy Lookup at all times.
DSAP provided implementation logic to efficiently process policy
verification without needing to do signature verification. This required
that the verifier also checked the policy first to handle the most basic
policies:
- No mail expected
- I never sign mail but it was signed
- I alway sign mail but it was not
- I don't allow 3rd party signers and it was.
I felt this will cover a major portion of the most obvious spoofing problem,
including those who didn't even try to use DKIM.
The SSP talks begin:
Well, it went crazy, because rather then begin with the original SSP draft
or my DSAP draft, they were ignore with what was the most surprising event
and I think was one of the primary causes for the chaos; Either some ask or
Michael Thomas volunteered to do Policy Requirements from scratch!!
The problem?
He exhibit signs he didn't understand. So we were starting brand new with
everyone debating semantics "usages cases", some calling for a reduced set
of policies, even though they even didn't understand them or the security
issues around them.
Basically a few wanted to water the policies down to 2-3, like
I sign all mail
I never send mail
and I felt this was totally wrong to just have these too.
But the way they phrased it and variations of it was obvious going to cause
debates.
My take is that the policies are already defined by what DKIM-BASE allows
you to do. In other words, DKIM-BASE told the story. You needed to address
all possible conditions otherwise you have loopholes.
Of course, we got Dave Crocker use the small is better philosophy but he
says he doesn't understand too, but then gives us his 1-2 polices only.
Of course, I didnt' help in many cases because I was coming from the other
angle of using a TOP DOWN approach. Lets look at all the possible policies
as defined by whats possible in DKIM-BASE and decide which ones we want.
Others want to start fresh and now in some cases, not at all.
The second cause for the chaos was John Levine begining a rthetorical
compaign and crusade, which in my view was to DoS the censensus process by
saying "No one understands SSP", "The SSP FOG Gets Bigger!" and then begins
to tell us we just need one or two, if any.
Phillip Halam-Baker even blurted:
"I am getting a bit fed up of folk who first say they don't
understand policy and then opine about what policy must
be and tell everyone else that they are wrong."
Phillip introduced his own proposal based on some existing proposal for
server policies or something. I think William can elaborate more on this.
He understood it better than I.
But we both agreed, as I added in DSAP, the need to have policy attributes
include hashing information to help the security.
But john ignores all input from anyone other than those who agree with him
and when the chaos grew more, he sees his opportunity and begins to ask the
rthetorical question, "I am getting the feeling we should drop SSP"
When a few started to agree, John would say, "Yeah, I always felt that way.
We should reputations systems instead."
But what he didn't tell you is that he just stated a new Reputation Business
venture called DAC and where he has no intention to use SSP.
http://www.domain-assurance.org/
As you can imagine any strong email policy system like SSP will not help his
business.
I felt this was a conflict of interest since he never had the intention to
support SSP or consider SSP in his business. In fact, he has a new protocol
VBR that adds a new header with Message Type and Domain List. He was
trying to stop SSP and several people offlist agreed. I was going to file
a complaint but I advise to hold back or ask the chairs about it. I was but
I never hit the send button. I should of done that. instead of what happen
next:
But then the final straw came when the person who was suppose to be writing
the Policy Requirements suddenly starting to say he didn't understand and
started to agree with John.
Thats is when I posted shot back some messages that I probably should not
done but it hit the heart of what was going on there.
My response when Michael suggested maybe we should stop SSP:
http://mipassoc.org/pipermail/ietf-dkim/2006q3/004978.html
My response when John admitted he didn't want SSP all along:
http://mipassoc.org/pipermail/ietf-dkim/2006q3/004982.html
From there, noting really happen any more but a private warning from the
chair and a statement from the chair the requirements draft will be out
shortly.
As Scott said to me, I made my point and I know I should step back.
SSP is too good technology to let die to greedy ambitions and self interest.
I know the IETF process and me do not mesh too well, and I know that. But
I'm too old to have regrets. <g>
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com