On Fri, Jul 11, 2014 at 10:08:59AM -0400, Rene Struik wrote: > One of my concerns with Optimistic Encryption is that it may have as side s/Optmistic/Opportunistic/ > effect that it may be tempting for implementers to move from secure and > authentic channel set-up to just encrypted (but unauthenticated) channels, > since it - how convenient - removes the need for any admin... Unauthenticated encryption is only appropriate where no current key management approach scales. If unauthenticated encryption is employed within an organization, that's a security failure that needs to be addressed by the organization's IT team. In parallel with advancing opportunistic security at Internet scale, we need to improve key management at enterprise scale. Make Kerberos easier to deploy. Make internal DNSSEC easier to deploy (and publish SSHFP and DANE TLSA records, ...). Making security ubiquitous is a battle on multiple fronts. I am hoping to define opportunistic security without mapping out the whole security landscape. Perhaps the larger landscape is a different document? Opportunistic security is intended to strengthen SMTP, HTTP and the like, not weaken enterprise applications or industrial control systems. I don't think the opportunistic security definition promotes sloppy internal risk management. However, if this is felt to be important to state explicitly, I think a sentence or two along those lines might be acceptable in the security considerations section. -- Viktor.