ietf
[Top] [All Lists]

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

2014-07-30 12:32:06
On Wed, Jul 30, 2014 at 11:54:21AM -0400, Stephen Kent wrote:

   3.  The draft variously permits or prohibits use of cleartext within
the context of the defined term.  This needs to be resolved, and carefully.

I would say:

"OS strives to greatly broaden the use of encryption in IETF protocols,
to combat PM. To facilitate incremental deployment, OS operates in
a fashion that may result in a plaintext connection/session."

This is I think addressed by the "Encrypt by default" principle,
but perhaps the below change helps to get the point across:

diff --git a/draft-dukhovni-opportunistic-security 
b/draft-dukhovni-opportunistic-security
index a708120..f957e25 100644
--- a/draft-dukhovni-opportunistic-security
+++ b/draft-dukhovni-opportunistic-security
@@ -128,7 +128,10 @@
      <t hangText="Encrypt by default:"> An opportunistic security
      protocol MUST interoperably achieve at least unauthenticated
      encryption between peer systems that don't explicitly disable this
-     capability.  Over time, as peer software is updated to support
+     capability.  To facilitate incremental deployment, opportunistic
+     security protocols may tolerate cleartext connections or sessions
+     with peers that don't support
+     encryption.  Over time, as peer software is updated to support
      opportunistic security, only legacy systems or a minority of
      systems where encryption is disabled should be communicating in
      cleartext.  Whenever possible, opportunistic security should employ

I am careful to avoid suggesting that there is a single protocol
called "opportunistic security", umbrella (marketing) term and all
that...  So I used the phrase "opportunistic security protocols",
which is already used elsewhere in the document.

-- 
        Viktor.

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