Re: Why we should authenticate multiple identities

On Sat, 18 Sep 2004, Meng Weng Wong wrote:

> A patent application is not a patent; I understand that
> nowadays applications are filed containing many claims that
> the filer doesn't actually expect to be approved, but if
> they are approved, bonus! 

At the same time we also heard that only the most obvious claims are 
rejected and that most are not and patent office is expecting that if
patent does not have a leg to stand on then it'll not be possible to 
defend in court.

> So let's look at which claims we
> can realistically expect to survive into patent form, and do
> our best to educate the patent office about the rest. 

It appears patent office will ignore any attempts to contact them
regarding patent applications other then your own (i.e. you can contact
them in regards to somebody else patent application only as long as it
has anything to do with your own patent application and they conflict).

> The ones that do make it into the patent may not turn out to be
> an encumbrance after all, or if they are an encumbrance at
> least we have a solid idea of how to route around them.
Hard to say...

> On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote:
> | 
> | I don't think that's true.  The domain/IP verification schemes
> | directly address forgery, in a way that CSV doesn't.  Think about
> | Sender ID as a tool for senders who (for whatever reason) want to be
> | able to prevent others from sending forged mail claiming to be from
> | them.
> 
> I agree that the anti-fraud aspects of SPF/Sender ID are
> stronger than CSV, and should not be abandoned just yet.

Lets separate SPF from SenderID - they are in no way equivalent terms.
I see these terms as follows:

"SPF" is protocol in a way that it defines record format for representation
of policy record in dns that can whitelist or blacklist certain ip addresses

"SPF Classic" (now SPF Mail From) is using SPF protocol to protect RFC2821 
Mail From (aka ReturhPath) identity of email system

SenderID is using SPF protocol to protect a validate new PRA identity based 
on combination of RFC2822 headers From, Sender, Resent-From, Resent-Sender

> CSV alone is not sufficient because it has a weaker
> deployment driver than SPF / Sender ID.  To wit:

Agreed. And CSV Authors themselve have proposed extensions to protect
RFC2821 Mail-From. 

> So it seems to me that the average domain owner has a more
> compelling case to do SPF than CSV.  I'm not saying nobody
> will do CSV: I fully expect ESPs and ISPs to do CSV on their
> MTAs, but you're not going to see uninterested parties
> putting negative CSV assertions on all the other hostnames
> that could be HELO'ed by MTAs.  By contrast, I expect many
> more people to put SPF records on their domains because the
> benefits are more immediate and more apparent.

I do not think that we should do CSV + SPF (but its not a strong believe 
as long as both are clearly standartized, its ok - I just think its easier
for implementation if ways to protect different identities is done in
simular way). I think that it would be better for overall standartization 
process if we go with either CSV+MPR or Unified SPF (From + EHLO + PTR + 
etc) with standard  defined list of protected identities base on each method.

> | As a tool for recipients, Sender ID and CSV both provide a hook on
> | which to hang reputation and accreditation systems, and I'm agnostic
> | as to which will work better in the real world, though my feeling is
> | that they may in fact turn out to be complementary.
> 
> I agree that they will be complementary.  In the same way
> that restaurants offer a variety of eating options to
> satisfy different needs, we should aim to offer a variety of
> authentication options to accommodate the market better.

Lets not compare Apples to Oranges ....

There is a need to diverse options in the business market place, but there
is also reason why we have unified list of standard internet protocols and
why we have IETF for that matter. 

As an example we have SMTP protocol that is defined and we dont have multiple
email systems (I note that in the IM world that is the case and its sad ...)
but we do have quite a number of diverse mail clients that users can use 
and its very good that is so as it offers several interfaces to the system
so that people can choose one that best suites their enviroment and his/her
behavior in it. But in the end all this systems talk to each other no 
matter how diverse. 

> I have been observing a pattern of fallacious debate which can perhaps 
> be called "winner takes all". 

I do not believe that is the case. What is happening is that we're trying
to decide on best technical solution that can become standard and by 
standard I mean something that everybody can implement. 

It is not unusual for IETF to consider multiple technical approaches on
how to implement something, just recently on CRISP WG we had two ways
for new whois database system - FIRS based on LDAP and IRIS based on XML 
over BEEP and both fully accomplished the requirements. In the LEMONADE
WG we had two proposals on how to implement remote email submission
that can include parts of existing email messages without downloading
them to MUA. DNS extensions WG considered two ways to implement IPv6 dns 
records (A6 and AAAA), MULTI6 is considering several approaches on
how to implement multihoming with IPV6, etc. There are lots and lots
of workgroups that had before them several proposals and approachesto 
solutiona and they had to choose one - that is part of standartization 
process.

It is in fact those situations where standartization failed and where
opposting standards exist that created problems for deployement such is 
the case of S/MIME and PGP and neither one has achieved wide deployment
as the programs supporting one often can not deal with the other type 
of signature. I do not wish to be in the same situation with solutions
created by this WG and if we create something it must be something
that everone can deply and implement and that verification systems
are compatible with each other. 

---
William Leibzon, Elan Networks:
 mailto: [email protected]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/