At 05:30 PM 5/23/2005 -0400, Mark Shewmaker wrote:
On Mon, May 23, 2005 at 11:53:40AM -0700, David MacQuigg wrote:
> At 01:05 PM 5/23/2005 -0400, Mark Shewmaker wrote:
>
> >So again, how *exactly* does an ID claim from an untrusted party help me
> >accomplish my listed goals?
>
> What you have listed as goals, the authentication of specific
identities, I
> regard not as goals, but as means to accomplish a goal.
No, those really are my goals.
If you're fixating on the fact that I'm mentioning spf in my goals, then
I can reword:
For the reject-if-forgery goals (the first three of my six listed goals),
I want to:
1. Reject because of the EHLO argument if it's forged according
to the helo domain owner's rules.
2. Reject because of the MAIL FROM argument if it's forged according
to the MAIL FROM domain owner's rules.
3. Reject because of the PRA argument if it's forged according
to the PRA domain owner's rules.
How does your ID proposal get me reliable knowledge of the exact
definitions of forgery from these three separate parties for these three
separate arguments without use of an additional reputation server that
says I can trust the ID domain's hearsay claim about these other domains?
If the declared ID authenticates, then we have our responsible party. We
don't need the other identities, unless the ID owner expects them to be
checked.
You keep saying that the ID declaration is hearsay. I don't understand
what you mean by that word. To me, it means information which is passed
on, rather than provided first-hand. The declared ID is always first-hand
information. The MAIL FROM and header information is passed on by
forwarders. The domain in control of the sending MTA puts its own ID in
the SMTP session. There is no excuse for using someone else's ID, even
when forwarding on behalf of some other domain.
I'm not sure I fully understand your objection, but if you can put it in a
short, clear statement, I will include it in my summary. Here is my
attempt to summarize.
Objection: As a receiver, I may want to run some authentication methods
that are not listed in the record provided by the owner of the declared
ID. Having a declared ID won't help me do that.
Response: It would most likely be a waste of time to look for
authentication records for methods that the declared ID doesn't list. If an
acceptable method is not listed, the mail should be rejected. Note: What
constitutes an acceptable method is up to the receiver, but it could well
depend on the ID's reputation. You might insist on rigorous checks for
B-rated domains, and just a quick check for A-rated domains. The
assumption is that an A-rated domain knows what it is doing, and any
failure of their approved quick check would lower their reputation.
> I would state the goal as "authenticating an offered identity, using
> whatever method is offered by that identity and is acceptable to me".
> This is a goal all methods can share.
Sorry, that's way too vague for me.
In any event, "an" makes it sound as if there's just one thing to
authenticate, which is clearly insane.
The record for a declared ID may specify, by the list of methods, what
identities are to be checked. Those identities can be different than the
declared ID, the declared ID is still responsible.
--
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 *
************************************************************ *