Dear colleagues:
One of my concerns with Optimistic Encryption is that it may have as
side 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...
I can already see arguments about why one should spend money on
authentication support if the attack window is so small, etc., akin to
discussions I have seen rampant in industrial control settings, where
some people have argued that communicating symmetric keys wirelessly
over the air for bootstrapping is okay, "since nobody would listen in
anyway". I think this is a major risk.
If this "substitution risk" would materialize, we might actually lower
the bar and set back the clock nearly 40 years, since realizing
encrypted, unauthenticated channels already proposed in the 1976 paper
on "New Directions in Cryptography".
Shouldn't one at least add some more extensive verbiage about security
policy enforcement? After all, reason to do authentication would be to
have some evidence on the party one is communicating with and can then
arrive at more fine-grained conclusions as to authorization and scope
hereof, based on that evidence.
The the day-to-day risk for security architectures may be increase of
admin cost if there would ever be a lifecycle event after initial
provisioning and where lack of authentication may really hurt.
Rene
On 7/8/2014 11:34 AM, Stephen Farrell wrote:
IETF LC started as promised.
Cheers,
S.
-------- Original Message --------
Subject: Last Call: <draft-dukhovni-opportunistic-security-01.txt>
(Opportunistic Security: some protection most of the time) to
Informational RFC
Date: Tue, 08 Jul 2014 08:09:40 -0700
From: The IESG <iesg-secretary@xxxxxxxx>
Reply-To: ietf@xxxxxxxx
To: IETF-Announce <ietf-announce@xxxxxxxx>
The IESG has received a request from an individual submitter to consider
the following document:
- 'Opportunistic Security: some protection most of the time'
<draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2014-08-05. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This memo defines the term "opportunistic security". In contrast to
the established approach of delivering strong protection some of the
time, opportunistic security strives to deliver at least some
protection most of the time. The primary goal is therefore broad
interoperability, with security policy tailored to the capabilities
of peer systems.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/
No IPR declarations have been submitted directly on this I-D.
This document and a predecessor have been the subject of discussion
on the saag mailing list. [1]
[1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html
_______________________________________________
saag mailing list
saag@xxxxxxxx
https://www.ietf.org/mailman/listinfo/saag
--
email: rstruik.ext@xxxxxxxxx | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363