ietf
[Top] [All Lists]

Re: [saag] Fwd: Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

2014-07-11 10:35:48
The definition does not promote sloppy risk management, its use may (history of 
practical use of security is embarassingly full of sloppiness and taking 
shortcuts).

Rene

==

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.


On 7/11/2014 10:27 AM, Viktor Dukhovni wrote:
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.



--
email: rstruik(_dot_)ext(_at_)gmail(_dot_)com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

<Prev in Thread] Current Thread [Next in Thread>