On Thu, 2005-11-17 at 21:32 -0500, Hector Santos wrote:
Can you explain how?
Forgive the size of this message, but you created a rather lengthy list
of items. I will try to keep it brief.
Showing the policies again:
o=? WEAK (signature optional, no third party)
What is the point?
o=~ NEUTRAL (signature optional, 3rd party allowed)
All types of spoofing allowed and thus worse than worthless. The mere
presents of this record justifies unfair reputation accrual at the
email-address. : (
o=- STRONG (signature required, 3rd party allowed)
Only signed spoofing allowed.
o=! EXCLUSIVE (signature required, no 3rd party)
Breaks current practices.
o=. NEVER (no mail expected)
Doubt this will find much use.
o=^ USER
Facilitates dictionary attacks.
Looking the #1 obvious scenario which you are concern about, where ISP user
(MUA) wishing to use an alias via his ISP machine:
Ease at exploiting this type of use ensures this is will not remain an
option without using multiple From addresses.
When the MUA submits a message, the ISP MSA will:
Sign the message and not expend the overhead checking policies.
So the only OA Domain (From) restrictive policies when the domain is used as
an alias domain at the MSA are:
o=! as nothing else offers protection, but then applications must change
significantly, and privacy and freedom are lost.
Please don't misunderstand, DKIM offers a tremendous advantage,
but reliance upon a domain being visually unique may have
been considered okay a decade ago.
I don't follow that thinking. It is still important today.
Should companies be expected to register every possible look-alike
domain? How much litigation will this require? But then again, why are
so many recipients only seeing the pretty name? What about the part of
the world that use puny-code domains? How many look-alike, character-
set, and pretty-name attacks remain possible today? There is a better
way to secure email with DKIM that does not require an eye test.
The naive user requires greater assistance.
Yeah, at the MDA, not at the MUA.
I would say both. Much of the ongoing spoofing can be handled at the
MDA caching binding assertions within the signature. All other types of
spoofing can be handled through "confirmed" or "requested" caching at
the MUA.
Don't expect them to discern when they are seeing the
pretty-name, various character set(s) declared from a
RFC2047 format, a particular character-set derived from
puny-code RFC3492, or perhaps worse, the
puny-code itself. : 0
I don't expect them to know anything, but they do expect that when they
receive a message via our services that we did our best to serve them and
not just pass junk to them to decipher and cross our fingers that one day
they will get a new MUA that is smarter and do things for them.
What is being suggested will not diminish the protection your customers
should expect. When they do obtain an improved MUA, they will be even
better protected without any expenditure establishing an array of
"authorized" signing-domain or dealing with multiple From addresses.
Even then, why do I want to change 5-6 MUAs for our system for a logic I can
add to a single entry point - the back end server?
At the MUA using the binding technique, even intra-domain spoofing can
be detected without the ISP checking email-adresses when signing the
messages.
Did you know there are bills in certain govs like in Canada that is making
it a requirement for ISP to have AVS software so that you don't pass the
buck to users?
The base DKIM signature is all that is needed, nothing else.
Do you understand the concern just expressed?
Yes, I completely understand your concerns and motivation as well for that
matter. I am not 100% sure you care to understand the various majority of
others concern.
Sigh. DKIM can offer far better protection than the simplistic policy
scheme allows.
But your concerns are more about the impact exclusive and strong policies
only will have, not the others, you are trying to fight policies that
high-value domains will very much like to control and regulate. They don't
want the FREEDOM on their domains.
Those other policies are illusory. Email-address reputation will thwart
these already rather meaningless policies.
I recommend that you:
1) Embrace DKIM,
No problem.
2) Help squeeue out the issues of SSP
SSP should go. When you consider that only a few domains may wish to
use the o=! mode owing to the limitations, then fumbling up label trees
for each and every other email-address hardly seems productive. Had
publishing a policy not invited unfair reputation at the email-address,
perhaps some of this groping could be mitigated by the list of do-
nothing policies that were created.
Caching bindings is not that hard. It is simply a matter of grabbing a
domain name and entering it in a zone. To check for a binding conflict,
query the zone. When local, this can take microsecond versus seconds.
3) Help make sure that DKIM is flexibility for expansion,
The binding technique can consider the class of the key.
4) Help make sure DKIM updates RFC 2821 for client FQDN
I don't understand what is needed here.
So once DKIM/SSP becomes widely adopted, your ideas would fit right in. In
other words, CSV/CSV, DNA will gain an entry and window of opportunity for
exploration and usage.
The desire is to see DKIM succeed. Each of these are separate issues,
but defend DKIM. I don't understand why you mention DNA?
I didn't need to tell you that the opaque-id idea DOES expose user privacy,
especially for our Wildcat! system.
An opaque-ID would be optional. This identifier could be persistent or
sequential, but would allow the sender to use any email-address they
desired. The opaque-identifier would be no worse than most message-IDs.
SSP would force the use of a particular email-address. This opaque-ID
would help deal with replay issues and isolate compromised systems.
Compromised systems represent a major portion of the abuse seen today.
I would ask "Why not the Message-ID?" We already use this for tracking and
dupe checking for over 20+ years. This is already cross reference per
message per domain per user.
Standardizing on a signed identifier that may be persistent and act as
domain label permits a revocation capability. This would not disrupt
the function of the message-ID.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org