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.

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

Reply via email to