|
Standards Strategy
2005-05-19 09:58:53
Looks to me like there are three possible outcomes:
1) A de-facto standard established by some large industry consortium.
2) A government-mandated standard.
3) An IETF standard.
The IETF doesn't want to get involved in the SPF/SenderID battle. The best
you can expect from them is no interference in how each group defines its
own method, and perhaps a standard within which all the methods can
operate. If I understand the IETF "consensus" process, any uncompromising
minority can block a standard. I expect that will block both SenderID and
SPF for many more years. And don't forget about CSV. They have a lot of
influence with the IETF, and a strong dislike of both SenderID and SPF.
How about a government standard? The FTC is considering such a
mandate. They can't force it on the world, but they do have enough clout
to break the current deadlock. They don't want to get involved either, but
Congress may demand it. If all US-based domains were required to
authenticate their email, the rest of the world would probably follow.
Looks like the most likely outcome will be #1, and we all know who has the
biggest consortium going. Let's keep this in mind as we discuss the
details of any proposed inter-operability standard. Which would we prefer,
a standard that accommodates all methods and will allow a superior method
to show its advantages, or one that allows only one method, the one with
the biggest market share?
At 06:44 PM 5/18/2005 -0700, William Leibzon wrote:
On Wed, 18 May 2005, David MacQuigg wrote:
At 03:59 PM 5/18/2005 -0400, Michael Hammer wrote:
On 5/18/05, william(at)elan.net <william(_at_)elan(_dot_)net> wrote:
>
> http://emailauthentication.org/summit2005/agenda.html
>
> This meeting has a lot of items in agenda on SPF but it seems to be
> controlled by "industry" in particular DMA, Microsoft and their friends
> are over-represented there and I suspect they will be talking about SID.
>
Actually, I believe they will be talking about SID as encompassing
SPF. There was a presentation at Information Security Decisions
(Chicago, May 8-10) where the presenter spoke of SID as the "successor
to SPF". I waved my hand and pointed out the Councils statement,
pointed out the potential for problems where PRA is applied to SPF1
records and suggested that anyone interested should check out the
SPF-DISCUSS list.
Personally I think the Council should step forward and force the issue
with the organizers of this conference. If the Council cannot control
their own standard then it isn't much of a standard. The fact that a
member of the Council will be there and NOT addressing the issues per
the stance of the SPF Council and SPF Community is a shame.
Seems like a futile battle to me. The best you can do is hold them back
for another year. If they really are abusing SPF1 records, the best way
to make that clear to the world is rapid deployment.
How does that solve anything when they are abusing the same records we are
asking people to deploy?
Is there some consequence to this abuse that will be noticed by people
using SenderID, maybe some mail that gets incorrectly classified? If so,
the backlash from users will be far more effective than any protests at
some Microsoft-sponsored conference.
No - the best way for resolution is education about what they are doing
wrong which would effectively stop their deployment and abuse either
directly at the end (people will not deploy solution that is abusing
another system) or stop it from at the standardization stage.
People care about results, not whether SenderID abuses SPF. When I listen
to advocates of the different methods, even if I agree with what they are
saying, it makes me want to walk away. This battle is turning everyone off
and will only cause further delay.
Don't give them any more time to patch their product until nobody can
tell what it is, but it is actually SPF1 in disguise. :>)
If they were doing 100% SPF1 and just called it something else for
convenience of marketing, I'd be fine with it actually and probably
everyone else here as well.
If they see only an SPF1 record, my guess is they will do exactly what is
required to get a correct result. Anything else would hurt their sales,
and they are not that foolish. Why are we wasting time speculating about
how they might screw up?
The best thing we can do right now is establish a simple protocol within
which all methods can operate, and the rest of the industry, not involved
in this competition, can move forward. I'm talking about simple things
like how the sender should declare its identity ( *how*, not *what* identity ).
You have serious misunderstanding about security protocols and email sender.
You can not mix multiple things together like that because name of the
connecting mail client (EHLO) is very different then persistent MAIL FROM
session identity and that is different then end-user targeted author name
and address of the message (From:), which may or may not be the originator
of transmission ("Sender:"). You actually have to have separate spec to
protect each identity and it has to be valid on its own. Email is
not authenticated just because some identity X has been authorized.
I have no misunderstanding that the different identities in an email are in
fact different. There is some commonality, however, and that is what needs
to be standardized. The identities we are talking about are all domain
names. The domain name chosen by a sender to authorize an email can be
sent in an SMTP command, without changing existing fields, and before any
data transfer. That domain name can be used by the receiver to do a DNS
query and find out what method(s) the sender uses. Then the proper
procedure for that method can be followed, including selecting which of the
other identities are to be tested.
The above does not mean you can not "hang" accreditation/reputation on one
specific identity but it has to be one and only one for that reputation
system and not just random one chosen at the time of transmission.
Who said anything about random identities? Did you read the draft, or just
the noise in the discussions? The declared Identity is the one accepting
responsibility for the transfer. Other identities may be checked, as
required by the various methods, but if the result is PASS, the declared
Identity accepts responsibility. Example: If the declared Identity offers
only a DomainKey, don't waste time checking the EHLO or MAIL FROM identities.
I'm actually working on the paper on this very topic. I'll make it
available very very soon and will try to explain this in detail.
Focus on what is practical, not some academic ideal. Think about how SPF
will work in an environment with other methods. If your proposal meets the
fundamental requirements I have outlined in draft-macquigg-authent-IOP, I
will support it.
Until there is at least a de-facto standard on this and a few other
simple items, there will not be widespread use of authentication,
domain-rating services will not emerge, and we will never get to the
point where every domain wanting to operate a Public Mail Server feels
the need to authenticate.
< snip petty argument on the meaning of "authenticate".>
I've written a few proposals, and I'm ready to submit one (the Identity
declaration) to the IETF. Anyone wanting to help is welcome. I'm
particularly interested in avoiding anything that will make it difficult
for SPF to adapt.
The Sender's Declaration of Identity proposal can be found at
purl.net/macquigg/email draft-macquigg-authent-declare in various
formats (txt, htm, rtf). There is also a discussion on ietf-smtp.
Its bad proposal because it mixes completely different identities
without any regard to what it means. You probably need to read a
more on topic of messaging security as I'm not really right person
to explain it and definitely can't do it in few sentences on the list.
I don't need any more patronizing expertise. What would be helpful is
pointing out where in the draft this misunderstanding occurs. I realize my
writing can be improved. In case you read an earlier draft, I have added
an example (highlighted in yellow) to clarify exactly how the declared
Identity is used.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *
|
|