----- Original Message -----
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Markus Stumpf" <maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net>
I think that based on all of the discussion here, it looks like all of
the technical details have either not been fully thought through yet,
and/or are not being publicly shared. So I guess we'll have to wait
until they release the full technical specs for the proposal, hopefully
addressing all of these issues.
Right, however....
The problem is if YAHOO is "truly" going to deploy on early 2004, that
really doesn't give anyone any time and more importantly it indicates they
(alliance?) have already "worked something out" and/or they are only truly
interested in stamping their own mail generated and going out their farm and
is telling the world, "hey, our mail headers will have private keys and
whoever supports it will be able to authenticate our mail." However, what
they are not saying is that HOW that is done and if this going to be
deployed within 1-2 months, they MUST have some arrangement with AOL,
Microsoft and Earthlink.
Worst case paranoid scenario: In time, once the public hollering quiets
down, the system is proven to work with the "Alliance." In the name of
security, the specification is proprietary is only given to certified mail
server developers under a NDA.
Anyway, with all that aside.
It seems to me that this Yahoo proposal is strictly designed around their
DATA validation methodology which in my opinion, minimized its adoption or
deployment effectiveness. (Which they don't care as long the 4 sisters are
together on it).
Technically, any private key concept must be applied with a 3+ tier system.
While only 2 end points is all that is required at a minimum, the trust is
magnified when one or more independent middle wares validates the key during
the route of the message.
This can be illustrated with a trust value table:
Each mail system have different designs, but in general, they have these
components:
- MUA: Mail Creator
- MUA: SMTP Sender
- MTA: SMTP Receiver (can be multiple routes)
- MTA: SMTP Router (final destination route)
- MTA: Mail Gateway (final destination storage)
- MUA: POP3 Client
- MUA: Mail Reader
It is conceivable at each of these components may be "involved" in the key
validation, including the POP3 server.
Why?
If this system is deployed, application developers can offer new options to
the user, i.e, Outlook mail pickup options:
[X] Rejected all non-YDK validated mail
[X] Accept YDK mail with trust value equal or greater than: 8
Give each component a sequential trust value, 1 through 7. Each component
can add a missing key or validate an existing one.
The trust of a transaction is the summation of the compliant components.
At a minimum, the endpoints yield a trust value of 8 (1+7).
At a maximum, with all components complying,the highest trust value is 28
(1+2+3+4+5+6+7+8)
I don't wish to draw out the total scenarios and trust values, but I wish to
point how I may use to determine where I would add a key to gain a high
trust with minimum compliance. In this case, it would be the POP3 server,
the final MUA plus one other component. In our design, since the gateway is
central for all mail formats coming into the system, it may be the best spot
for us. So:
- MTA: Mail Gateway (final destination storage)
- MUA: POP3 Client
- MUA: Mail Reader
with a trust of 18 (5+6+7).
This tells me this is better than having
- MUA: SMTP Sender
- MUA: POP3 Client
- MUA: Mail Reader
with a trust of 15 (2+6+7).
This works for us, because we mail also have:
- MTA: Mail Gateway (final destination storage)
- Web Mail Server
- MUA: Mail Reader (Browser)
or
- MTA: Mail Gateway (final destination storage)
- Telnet Mail Server
- MUA: Mail Reader (Telnet client)
or
- MTA: Mail Gateway (final destination storage)
- GUI Mail Server
- MUA: Mail Reader (GUI client)
etc, etc.
In other words, for YDK, I see this:
1) It assumes mail is received (DATA state).
2) For some systems, it may be best to apply it only at the final
destination component and this may not be a SMTP system but simply a RFC822
compliant system.
3) And that this may be best applied at the POP3 server (mail pickup) level
because it offers end-users new options at the application level.
I believe that any proposal that has its basis with mail content validity
vs. mail sender validity, is not something SMTP should be involved with.
(SMTP should strictly deal with the validation of the transport, like LMAP,
SAP and others.) While SMTP can help the process (such asp non-RFC822 MUA
systems), a proposal that will not have full deployment is simply beating a
dead horse. With minimum deployment, this YDK proposal works best at the
endpoints plus the pop3 server which seems to be exactly what YAHOO is doing
with an early 2004 release.
-- Hector
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg