On Tue, Jun 19, 2012 at 5:49 AM, Chris Lamont Mankowski < makerofthing...@gmail.com> wrote:
> I realize my last message talked about TLS-OBC for SMTP but didn't preface > it with any information on how I see how it can replace, or compliment SPF > in a given situation. First, does anyone know of a working group that is > getting TLS-OBC to work in conjunction with the SMTP protocol? Perhaps > some of this information is written elsewhere. > * > * > TLS-OBC allows for a SMTP server to publish its public keys into DNS, > while removing any dependency (or > vulnerability<http://security.stackexchange.com/q/2268/396>) > on the PKI hierarchy. The approach works at the envelope layer (just like > SPF) and has the potential to allow a sender to simply have a private key, > instead of sending mail from a particular IP address. This alone > simplifies configuration and allows for many deployment models. > > Based on what I've read, in order for TLS-OBC to be secure the > corresponding DMARC-TLS policy should define if DNSSec should be used for > the certificate, CRL and OCSP links. I personally want to also specify > cipher and encryption levels as well, but I can see how that can fall out > of DMARC's scope of message authentication. Conversely, if a certificate > is being used in situations to replace SPF, then we should specify the > minimum crypto allowed (we don't want MD5 for example) > > For those who are interested, here is information on why DNSSec is > required <http://security.stackexchange.com/q/6824/396> and additional > information on how easy it is to spoof > DNS<http://security.stackexchange.com/q/6827/396> > . > > > This also sounds like it's on the wrong list. I suggest ietf-s...@ietf.org. Seems to have very little to do with DKIM. -MSK
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
