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]

 



----- Original Message -----
From: "Viktor Dukhovni" <ietf-dane@xxxxxxxxxxxx>
To: <saag@xxxxxxxx>
Cc: <ietf@xxxxxxxx>
Sent: Wednesday, July 30, 2014 4:08 P


> On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote:
<snip>
> I like "all or nothing", "all" here is sensibly read as "everything
> implemented", not "everything possible".  Thus simply a binary choice.
>
> However, in trying to work this into the text I am finding that it
> becomes more verbose, and spends too much time on inessential
> details.  Perhaps this is just failure to craft the right text on
> my part, but I am having a hard time actually improving the text
> overall, even though "all or nothing" is perhaps better than "strong".
>
> There is a tension here between a quick informal description of
existing
> practice, that should be clear to most, with a clear focus on the new
> model, and a more accurate/detailed description of past practice, that
> might detract from the focus of the document.
>
> Is anyone willing to take the time to carefully update the
Introduction
> to find the sweet spot between the current cursory nod to the past on
> one extreme, and potentially an overly elaborute detour on the other?
>
> I tried a couple of times, but have not yet succeeded.  Writers
> block and shortage of cycles perhaps...

How about

" Opportunistic security encourages peers to employ as much security as
   possible, without falling back to unnecessarily weak options.  In
   particular, opportunistic security encourages unauthenticated
   encryption when authentication is not possible.

  Without key management at an Internet scale,
   authentication is often not
   possible.  When, as a result,  protocols only offer the options of
either strongly
   authenticated secure channels, or else no security, traffic commonly
gets
   no security.  Therefore, in order to make encryption more
   ubiquitous, authentication needs to be optional.  When strongly
   authenticated communication is not possible, unauthenticated
   encryption is preferable to clear text.

  Historically, Internet security protocols have prioritized strong
   protection, for peers capable and motivated to absorb the associated
   costs and this has lead to most traffic being unprotected.  The fact
that most traffic is then
   unprotected facilitates pervasive monitoring (PM
   [RFC7258])  by nation states, by making such practices cost-effective
(or, at least, not cost-
   prohibitive).  Such indiscriminate [widespread?] collection of
communications traffic
   would be substantially less attractive to nation states if security
protocols
   offered a range of protection levels, offering encrypted
   transmission to most, if not all, peers and offering stronger
   security when required by policy or by opportunistic negotiation.

   Encryption remains easy, key management is difficult.  Key management
   at Internet scale is an incompletely solved problem.  The PKIX
   ([RFC5280]) key management model introduces costs that not all peers
   are willing to bear and also cannot secure
   communications when either the reference identity of the peer is
obtained
   indirectly over an insecure channel or the communicating parties
   cannot agree on a [root?] certification authority (CA).  Thus DNSSEC
is
   not at this time sufficiently widely adopted to make DANE a viable
   alternative at scale, while trust on first use (TOFU) key management
   models (such as with saved SSH fingerprints and various certificate
   pinning approaches) fail to protect initial contact; and, also,
require user
   intervention when there is a failure of key continuity.
"

I think that the paragraph order is key! Currently it is deductive, fine
for academic texts, less so for RFC, hence my switch to inductive.

Tom Petch

>
> I think that if we change nothing, though the document could likely
> be improved, that the improvements are inessential.  Perhaps we
> can leave well enough alone?
>
> --
> Viktor.
>
>





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