Dear John-Mark, Good Questions. See brief comments inline.
On Oct 23, 2013, at 1:02 PM, John-Mark Gurney <[email protected]> wrote: > Douglas Otis wrote this message on Wed, Oct 23, 2013 at 12:47 -0700: >> On Oct 23, 2013, at 11:44 AM, Dave Crocker <[email protected]> wrote: >> >>> On 10/23/2013 2:34 PM, Noel Torres wrote: >>>> On 23/10/13 19:18, Dave Crocker wrote: >>>>> On 10/23/2013 2:13 PM, Noel Torres wrote: >>>>>> I think it would be possible, and even easy for the developers, to >>>>>> program an extension to SMTP in which servers use OpenPGP among them, >>>>>> independently of any TLS/SSL usage. >>>>>> >>>>>> Why: It helps stopping spam because the receiver server can trust the >>>>>> identity of the sender, and it helps avoiding wiretapping. >>>>> >>>>> Please explain it's superiority over DKIM and SPF and DMARC. >>>>> >>>>> d/ >>>>> >>>> Hi Dave >>>> >>>> In short, DKIM does not avoid wiretapping on itself, SPF does not, >>>> either, nor DMARC. >>> >>> You cited the benefit you are seeking as trusting who the 'sender' was. >>> That's an authentication/signature task, not a confidentiality/encryption >>> task. >>> >>> d/ >>> >>> ps. the mere fact of authentication does not vet the trustworthiness of the >>> validated identity. >> >> Dear Dave, >> >> As you know, DKIM can not authenticate the sender. DKIM authenticates some >> unseen domain signed a portion of the message. DKIM does not confirm the >> signing domain intended to send the message to the recipient either. Nor >> does DKIM ensure valid message structure where acceptance on the basis of >> trusted DKIM signatures can be hazardous, contrary to the process described >> in the DKIM deployment RFC. In addition, because DKIM can not authenticate >> the sender, it can never abate email abuse either, nor was that ever >> described as a supported feature. > > What is your definition of sender? The sender can be many different > entities in this context.. I can be the relay, it could be the domain's > email server or it could be the end user... Based on whatever definition used, an entity held accountable for sending a message to a recipient not desiring its receipt should be authenticated for having actually issued the message to said recipient. DKIM can not do this. It only indicates an unseen signing domain handled the signed portion of the message and nothing more. > From my understanding, DKIM is basicly a statement from a responsible > domain, that I have done my best to validate that this is a legitimate > email and I don't relay for untrusted people, etc... Responsible for what? When the DKIM mechanism fails to ensure elements needed to hold domains accountable for unwanted email abusing a recipient, it would be unwise to assume the domain is therefore responsible. Any such assumption can be easily poisoned. >> StartTLS is not affected by message structure and indicates the intended >> recipient as well as identifying an accountable sender. StartTLS offers a >> safe basis for trust, reputation, and acceptance. DKIM in conjunction with >> DMARC has very limited applicability and only prevents From header field >> spoofing but even then allows click-able links to be injected into a spoofed >> Subject header field. > > Maybe I'm missing something, but I'm not sure how STARTTLS (plus presuably > w/ DANE) can authenticate that the client is the sender? I might be > missing the RFC/standard/etc. that allows server to auth the client cert.. Normally the critical aspect when submitting a message is to ensure credentials are shared with the intended submission server. This is where StartTLS is normally used, but StartTLS can also exchange client certificates. Since client certificates become essential when accepting encrypted email over IPv6, perhaps the presence of a DANE certificate located at the MX could automatically signal a paradigm change. > In most cases I've seen, it's only the client/relay authenticating server.. You mean StartTLS verifying the domain of the server requesting client credentials? Then yes. >> ps. DKIM authentication does not vet the message nor the trustworthiness of >> the signing domain. DKIM does not validate any identity either. > > As far as my understanding, nor does STARTTLS... This represents an unused feature that could greatly strengthen and protect all forms of email. Abuse would drop significantly within a new paradigm that safely permits the establishment of domain reputations, while also enabling services to operate safely from any IP address and from any provider. Not even Reverse DNS has less overhead when DNS timeouts are considered. Regards, Douglas Otis _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
