Proposed wording updates to address some of Steve Kent's comments
(plus one or two minor other fixes). Note, this is not a major
rewrite or restructuring. Just nit fixes.
diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security
index ff29c55..c3ff1a3 100644
--- a/draft-dukhovni-opportunistic-security
+++ b/draft-dukhovni-opportunistic-security
@@ -55,7 +55,7 @@
comprehensive protection against both passive and active attacks
- for peers capable and motivated to absorb the associated costs.
+ for peers able and motivated to absorb the associated costs.
Since protection against active attacks relies on authentication,
which at Internet scale is not universally available, while
- communications traffic was sometimes strongly protected, more
- typically it was not protected at all. The fact that most
+ communications traffic is sometimes strongly protected, more
+ typically it is not protected at all. The fact that most
traffic is unprotected facilitates nation-state pervasive
@@ -67,4 +67,4 @@
accessible to most if not all peers, and protection against
- active attacks still available where required by policy or
- opportunistically negotiated.
+ active attacks still employed where unconditionally required
+ by policy or else discovered to be possible with a given peer.
</t>
@@ -74,10 +74,10 @@
management at Internet scale remains an incompletely solved
- problem. The PKIX (<xref target="RFC5280"/>) key management
+ problem. The Web PKI key management
model, which is based on broadly trusted public certification
authorities (CAs), introduces costs that not all peers are
- willing to bear. PKIX is not sufficient to secure communications
+ willing to bear. Web PKI public CAs are not sufficient to secure communications
when the peer reference identity (<xref target="RFC6125"/>)
is obtained indirectly over an insecure channel or communicating
- parties don't agree on a mutually trusted CA. DNSSEC (<xref
- target="RFC4033"/>) is not at this time sufficiently widely
+ parties don't agree on a mutually trusted CA. At this time,
+ DNSSEC (<xref target="RFC4033"/>) is not sufficiently widely
adopted to make DANE (<xref target="RFC6698"/>) a viable
@@ -93,3 +93,3 @@
When protocols only offer the options of authenticated secure
- channels or else cleartext, most traffic is sent in the clear.
+ channels or cleartext, most traffic is sent in the clear.
Therefore, in order to make encryption more ubiquitous,
@@ -97,5 +97,6 @@
communication is not possible, unauthenticated encryption is
- still substantially stronger than cleartext. Opportunistic
+ preferable to cleartext transmission, in that it addresses
+ pervasive monitoring <xref target="RFC7258">. Opportunistic
security encourages peers to employ as much security as possible,
- without falling back to unnecessarily weak options. In
+ without falling back on unnecessarily weak options. In
particular, opportunistic security encourages unauthenticated
@@ -159,4 +160,5 @@
goal of designs that feature opportunistic security is to be
- able to communicate with any reasonably configured peer. If
- many peers are only capable of cleartext, then it is acceptable
+ able to communicate with any correctly configured peer. If a
+ non-negligible number of potential peers are only capable of
+ cleartext, then it is acceptable
to fall back to cleartext when encryption is not possible. If
@@ -164,10 +166,12 @@
acceptable to authenticate only those peers and not the rest.
- Interoperability must be possible without a need for the
+ Interoperability must be possible without a prior need for the
administrators of communicating systems to coordinate security
- settings. Applications employing opportunistic security need
+ policy. Applications employing opportunistic security need
to be deployable at Internet scale, with each peer independently
configured to meet its own security needs (within the practical
- bounds of the application protocol). Opportunistic security
+ bounds of the employed protocol). Opportunistic security
must not get in the way of the peers communicating if neither
- end is misconfigured. </t>
+ end is misconfigured (i.e., neither publishes or negotiates
+ security services that are not available or don't function
+ correctly). </t>
@@ -176,7 +180,7 @@
security strives to maximize security based on the capabilities
- of the peer (or peers). For some opportunistic security
+ of the peers. For some opportunistic security
protocols the maximal protection possible may be just
unauthenticated encryption to address passive monitoring. For
- others, protection against active MiTM attacks may be an option.
- Opportunistic security protocols may at times refuse to operate
+ others, protection against active attacks may be an option.
+ Opportunistic security protocols may, when applicable, refuse to communicate
with peers for which higher security is expected, but for some
@@ -192,3 +196,3 @@
this capability. To facilitate incremental deployment,
- opportuistic security protocols may tolerate cleartext connections
+ opportunistic security protocols may tolerate cleartext connections
or sessions with peers that don't support encryption. Over
@@ -213,6 +217,6 @@
encompasses protocol designs that remove barriers to the
- widespread use of encryption in the Internet. The actual
+ widespread use of encryption on the Internet. The actual
protection provided by opportunistic security depends on the
- capabilities of the communicating peers; opportunistic security
- MUST attempt to at least encrypt network traffic, while allowing
+ capabilities of the communicating peers. Opportunistic security
+ MUST at least aim to encrypt network traffic, while allowing
fallback to cleartext with peers that do not appear to be
@@ -228,3 +232,3 @@
MAY be a reason to abort a connection to a peer that is expected
- to be authenticated, it MUST NOT instead lead to communication
+ to be authenticated, it MUST NOT then lead to communication
in cleartext when encryption is an option. Some Message
--
Viktor.