Template talk:Internet security protocols

SPF and SenderID

I've copied the following from a WP:LEAD discussion. -- Omniplex 20:33, 21 April 2006 (UTC)

Seems a bit rich to point to your own essay as support for this deletion. As a matter of fact you are entirely wrong about SPF not being a security protocol, on the contrary it is a mechanism for authenticating emails by means of path validation. It is not a cryotographic security protocol but that does not mean it is not a security protocol. The alternative was to have folk continue to fill the front half of the S/MIME article with misinformed claims about its relationship to PGP.

There are now five email message security protocols that are either IETF standards or soon to be IETF standards. In addition there is the STARTTLS option in SMTP and the possibility of using IPSEC for transport security and even DNSSEC. The relationship between the different standards is quite complicated and there is a considerable degree of overlap. For example S/MIME makes extensive use of PKIX. It is also possible to make use of PKIX with PGP. Rather than have all the articles contain recapitulations of each other it is much cleaner to see how the cryptographic protocol stack works together. --Gorgonzilla 03:02, 8 April 2006 (UTC)

When you say "As a matter of fact you are entirely wrong about SPF not being a security protocol" you're probably talking about the 98% of its RFC not written by me. But I contributed to the SPF article here, and populated Category:E-mail authentication, updating some of its articles. You're the first telling me that that's entirely wrong. If SPF is a security protocol, then ROT-13 and Base64 are advanced cryptography.

SPF FAIL allows to block mail coming from IPs not permitted by the domain of the sender (Return Path for SPF, PRA for Sender-ID), that's per se not secure, think about shared hosts (same IP with many users). Only if you combine it with RFC 2476 section 6.1 "enforced submission rights" (optional), and minimally CRAM-MD5 ESMTPA, better ESMTPS, it can be a secure solution (depending on the sender policy, the weakest permitted ISP is an attack vector). ESMTPS (STARTTLS) is unrelated to IPSEC, but I agree that that's not yet covered completely by the SMTP-AUTH article. For S/MIME I had added links to MIME and TLS after removing your infobox. BTW, the infobox isn't deleted, "Tfd" is a proposal for deletion. -- Omniplex 03:48, 8 April 2006 (UTC)

You are not a security expert, I am. I know every one of the authors of SPF, SenderID, DKIM. I know all the living authors of PEM, S/MIME and PGP. I have met most of them personally in the past two months. You are dead wrong on this point. SPF is a security protocol. DKIM is chartered in the Security area of the IETF. SPF was only chartered in Applications because they knew that I would have delayed an attempt to start it in Security. The point of SPF was adding a security policy layer in to the IETF protocol stack. It is not in itself a cryptographic security protocol but it is a component of a security protocol. --Gorgonzilla 22:51, 21 April 2006 (UTC)