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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]