Subject: [saag] comments on draft-kent-opportunistic-security-01

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 01:20:44 +0100

Hi Steve,

Here are my comments on draft-kent-opportunistic-security-01.
(With no hats etc.)

I think there're a bunch of smallish fixes needed but we're
closing in on getting there I hope. (I'll send some suggested
text in a separate mail)

Cheers,
S.

- Title: I'd suggest just "Opportunistic Security"

- Abstract shouldn't have references

- I'd not emphasise STRINT so much, its worth a
mention and a reference in the intro but ins't
really important in the abstract.

- PM is not the only or main target for OS IMO.  PM
is what has motivated this and things like STRINT,
but we want to strengthen the Internet's security
mechanisms (and improve deployment) while addressing
PM. So I don't think PM is the main reason for OS at
all.

- Intro, 1st sentence: I'd add at the end "which can
also improve overall Internet security against other
threats as per the goals of the STRINT workshop
[STRINT]" which is probaby enough mention of STRINT
really.

- Intro, 2nd sentence: s/authentication/endpoint
authentication/ might be better and s/the major/ a
major/

- Intro, delete sentence with "flurry" - its not
needed

- Intro, para 2: suggest s/precise meaning/precise,
albeit not widely used, meaning/

- Intro, para 2: suggest referring to STRINT not as
a "basis" for this but as per the above, so maybe
delete this last sentence.

- Definition: OS "is a set of mechanisms" seems
wrong.  Rather OS is descriptive term that may
or may not apply to a given protocol.

- Definition: suggest removing "(for realtime
communication)" could be confusing with WebRTC or
RAI and would be odd to say realtime for e.g. MPLS.
And who knows, we might find useful ways to apply
this to store-and-forward as well.

- Definintion: I think what we want to present here
are a set of conditions the conjuntion o which is
sufficient for something to properly use the term
OS. The current list is close to that but not that.

- Definition-1: "is invisible" is too much I think.
It'd be silly if we had to pretend not to be
encrypting for example, I think what needs to be
stated is that we don't make the lock-icon mistake
again really.

- Definition-2: I like Nico's floor/ceiling way of
describing this, suggest getting him to craft a bit
of text for this aspect.

- Definition-2 and general: we should only speak of
a user when we really need to say that. So s/to a
user// here.

- Definition-2: I don't get the MUST here. The
existence of OS doesn't cause anything else to not
exist.

- Definition-3: "will make use of" is IMO too
strong, "strongly recommended" would be correct.

- Definition-4: I'm not sure what this is saying.
If what you want to say is that the server-auth
model commonly used with TLS is "ok" then just
saying that is probably better. (But I think Nico's
floor/ceiling may be useful there.)

- Definintion-5: the "only if" here is too much, I
think you want to say that endpoint authenticaiton
is preferable to just MITM detection. (But then
points 2 and 4 do that already don't they?)

- Definition-6: Suggest deleting "human-perceptible"
as any delay can be considered a problem. I also
think that point would be better separated from the
delayed authenticaiton one. (And I think the last
two sentences aren't really needed.)

- Definition-7: I think what you'r saying here is
that if you fall back to cleartext to get interop,
then your protocol may still be properly terms OS.

- Section 2: A minor point - describing TLS server
auth as a prior unilateral arrangement is good. In
fact TLS server auth is a tri-lateral arrangement
between clients (e.g browsers) with trust anchors,
CAs and servers.

- Section 2: The last para doesn't really belong
here and I think all that was already stated so I'd
say delete that maybe.

- Section 4, last para: The "then attempt to
upgrade" part seems wrong - with OS we do stuff and
might then upgrade if we can and if that makes sense
for the protocol concerned.

- Section 5: I'm not sure we need this really. I'd
suggest deleting it. If we keep it, then its has to
be clear what's copied from 4949 and what's modified
(and how) and what's new.