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-08-08 09:36:35

Hiya,

There are my own comments on the -02 version (with no
hat, so take 'em same as anyone else's). These are
based on -02 not fully considering other changes
proposed on the list, but intended to be merged with
those, as appropriate.

Cheers,
S.

(1) abstract: a couple of tweaks, here'd be my suggestion:

"This memo defines "opportunistic security" as a
protocol design pattern that contrasts with the approach of
specifying protocols that only offer implementers or
deployers a choice between no cryptograhpic protection and
protection against both passive and active attacks.
Protocols following the opportunistic security pattern
strive to deliver at least some protection most of the
time.  The primary goal is therefore broad interoperability
while enhcancing security overall, in a way tailored to the
capabilities of peer systems."

But that's just one suggestion, please merge with other
points raised.

(2) Too many run-on multi-clause sentences, e.g. "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." Please do a
pass where you try to shorten all long sentences e.g.
by splitting them up - it really makes for an easier
read.

(3) Call it a pattern throughout, e.g. change
"Opportunistic security encourages..." to something like
"Protocols using the opportunistic security pattern
encourage..."

(4) Yes, move the definition to the start of section
3, as recommended by most people. And define it as a
pattern.

(5) PFS is defined in 4949, just refer to that for
any such term without re-defining. Leap-of-faith
is in 4949 and is == TOFU so you just need to
refer to 4949 and state they're synonyms.

(6) Unauthenticated encryption is not in 4949 so you
do need that but please also say that this is *not*
the opposite of authenticated encryption as defined
in RFC 5116 but means a case where the endpoints for
encrypting and decrypting are not authenticated.

(7) "...unauthenticated opportunistic security is not a
substitute." is wrong I think perhaps better would be
"...an outcome of OS without endpoint authentication is not
a substitute."

(8) I'd get rid of "umbrella" and replace that with
"design pattern"

(9) The -02 definition paragraph (2nd last in section 3)
is still too negative (it mostly says what OS is not).
I think there was better wording on the list.

(10) Add something to sec. cons. saying that (as per
Rene's point) if you go from a state where you have
working mutual-auth+encryption to one where you use
OS for those same peers then you might be making
life worse. However, if you go from a state where
you have mutual-auth+encryption for only a few pairs
of peers to one where you succeed in the OS game
for many peers, then you may have made things better.

(11) Author's call, but were it me, I'd add an ack to
anyone who commented usefully on saag or the LC thread.

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