----- Original Message -----
From: "Viktor Dukhovni" <ietf-dane(_at_)dukhovni(_dot_)org>
To: <saag(_at_)ietf(_dot_)org>
Cc: <ietf(_at_)ietf(_dot_)org>
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.