ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

2003-12-08 19:13:47
Keep in mind that this proposal will only work if the RFC specifications are
clarified due to one its central criteria.  Quoting Yahoo:

"If the receiving system can decrypt that private key with a public key
registered by the Internet's Domain Name System, then it will be assumed the
message is authentic. If it can't, the message is bounced back from whence
it came."

Therefore, like other proposals, if the bounce system is not reliable or
considered or interpreted as "optional", then there can only be one
assumption to be made; throw the message away.

In other words,  what will be the RFC guidelines on handling an unreliable
or incomplete bounce due to a failed decryption of a private key?

This still needs to be addressed.  You guys need to get going with this
because whether you understand this or not,  once YAHOO implement it,
software vendors, such as myself have no choice but to add support for it.

The way I view this or any proposal for that matter, is how will it fit into
the complete integrated mail system of our product, where will the
validation process take place?

For example, if YDK is to be deployed,  we might consider the implementation
to be placed at various points of the process.

In essence, the baseline compliance for this proposal is two MUA systems.
The middle ware is not really required.  However, trust increases as a 3rd
party component is involved in the validation process.

If a compliant MUA sender is used,  does the SMTP route have a role of
validating the key or simply pass it on to the final destination?

If a non-compliant MUA sender is used,  where in the SMTP process does it
add the private key? or does it?

Is there sufficient trust when the MUA receiver is not compliant and the
SENDER is validated by SMTP?

Does the POP3 server play a role?   Can an enhanced MUA POP3 client informed
the enhanced POP3 server to accept or not accept  non-validated YDK mail.

In short, once this or any system is put in place,  the users will
ultimately have to decide if the non-validated private key email should be
received by the system and that's something that needs to be programmed in
the SMTP software.

Private key or not,  vendors will have to offer the option to the admins on
how to handle mail that has yet in compliance with the system.

Quick example:

Confirmed YDK-Ready Mail Sender ->  SMTP passes on the mail.

Unconfirmed YDK-Ready Mail Sender ->  What happens with unreliable bounce?

No YDK header Mail Sender ->  Should SMTP confirm the sender (and how?) and
add the header?

It just seems to me that YDK works with widely deployed.  In the mean time,
the RFC needs to be updated to provided the control mechanisms when ANY NEW
SYSTEM is not confirmable or validated or used.

That all boils down to the bounce concept.

Bounce is possible - GREAT!
Bounce not possible - scratch your head.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com


----- Original Message ----- 
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Alan DeKok" <aland(_at_)ox(_dot_)org>
Cc: <asrg(_at_)ietf(_dot_)org>
Sent: Monday, December 08, 2003 3:35 PM
Subject: Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"


Alan DeKok wrote:

Mark Baugher <mbaugher(_at_)cisco(_dot_)com> wrote:

It's not clear to me what Yahoo is proposing since the descriptions I
have
read don't make much sense.  But the first question I have with any
signature proposal is "what does the signature attest to?"


  The signature is most likely done on a hash of the message body
and/or some headers from the envelope.

  What it *means* is another question entirely.


The signature attests to the fact that the domain name or server from
which the message originated, is not forged.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>