On Mon, Oct 7, 2013 at 10:33 AM, Paul Wouters <[email protected]> wrote:
> On Thu, 3 Oct 2013, Douglas Otis wrote: > > Several have expressed valid concerns regarding abuse of encrypted email. >> > > One can always request encrypted email is signed. Than an abuser's key > can simply be blacklisted. Or all encrypted but not signed email can be > refused or disgarded. Encryption and key verification in DNS is actually > a really good anti-spammer tool. Note that this would require Encrypt-then-Sign or Sign-then-Encrypt-then-Sign, either of which has some security implications. <http://tools.ietf.org/html/rfc5751#section-3.6> --Richard > > > That said, proprietary schemes are available permitting multiple decoding >> keys derived from conveyed indexes. The derived keys are >> assigned to outbound message scanners used by enterprises to >> ensure governmental data compliance requirements while also ensuring the >> integrity of the entire path traversed. If there is interest, I could >> prevail on my employer to disclose IPR terms and details. >> > > Generaly, I think people are only interested in hearing unencumbered > ideas. So unless your employer has license terms that are unrestricted, > I at least do not wish to hear it. > > > Secondly, while web based TLS exchanges normally ignore client >> certificates, this would not be desirable for StartTLS related to open >> email exchanges. Currently, only source IP addresses are effectively >> used to defend SMTP servers. >> > > See above. If that is a concern, simply block encrypted but unsigned > email. Or only allow signed email if the public key is available in DNS. > > > IPv6 will significantly challenge the use of source IP addresses. >> > > Someone should tell Paul Vixie that, his ipv6 reverse check is > preventing me from emailing him on various occasions when my mail > client happens to get some v6 address :P > > > Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA >> records and SMTP security via opportunistic DANE TLS offer >> interesting starting points. For this to work well, a more disruptive >> approach is required where sending domains should be encouraged >> to use their own certificates. The initial availability of TSLA RRs >> should not miss the opportunity to use this to signal a new >> paradigm of expectations. >> > > I am not sure what you are saying here? > > encryption is unrelated to authentication or authorization. spam and > verifiable email origin are unrelated to encrypted the content (and/or > meta data) of email. It just happens that we used to use the content > and/or metadata to mark bogus email as spam. Clearly that has to change > if we are successful at hiding those properties from passive attackers > as well as anti-spam technologies. > > Paul > ______________________________**_________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass> >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
