Opportunistic Security: Some Protection Most of the Time
RFC 7435

Note: This ballot was opened for revision 05 and is now closed.

(Richard Barnes) Yes

Alissa Cooper Yes

Comment (2014-11-24 for -05)
No email
send info
Thanks for all the work on this, much improved.

= Section 3 =
"In general, communication
      should be at least encrypted."

I agree with this, but it is a little out of sync with the more factual description given in Section 1.2. I also don't know if it's supposed to have a normative feel (the goal should be, at a minimum, encryption) or a descriptive feel (one can expect communications to be, at a minimum, encrypted). Clarification and streamlining with what is said in 1.2 and immediately preceding this sentence would help -- perhaps by just deleting this sentence?

(Stephen Farrell) Yes

Comment (2014-11-19 for -05)
No email
send info
Just a yes:-)

Barry Leiba Yes

Comment (2014-11-19 for -05)
No email
send info
This second last call has resolved all the questions I had about this document, and I'm keen to see it move forward.

I'll make one note about Stephen's notes:

  There is no IANA considerations section and no need for 
  one. It'll be interesting to see if this note gets noticed or if
  folks complain about the lack of a redundant section.
  I hope the former and not the latter:-)

I'm neither complaining nor objecting about the document.  But I will point out that RFC 5226 is a BCP that defines our process, and we're supposed to follow it.  This note shows an unfortunate disdain for the process that we (the IESG) are supposed to be tending.

(Ted Lemon) (was Discuss) Yes

Comment (2014-11-25 for -05)
No email
send info
Thanks for addressing my discuss.   I'm very happy to see this document progress!

(Kathleen Moriarty) Yes

Comment (2014-11-23 for -05)
No email
send info
I support this document moving forward and think it is important to have the concepts defined and documented.  Thanks for your work on this draft.

I'd prefer some alternate text to the first paragraph of page 4, but realize this is just a preference and will let it go instead of proposing new text.

(Pete Resnick) (was Discuss) Yes

Comment (2014-11-24 for -05)
No email
send info
The last sentence of replacement paragraph for section 3 in the RFC Editor Note is distasteful. Discussion of the "transition" from broken algorithms to good ones (let alone the transition from cleartext to encrypted) is really orthogonal to the purpose of this document. But if the sponsoring AD (and the IESG) truly believe that saying such a thing represents the consensus of the IETF, I am willing to hold my nose on this sentence. I am otherwise fully supportive of this document.

(Jari Arkko) No Objection

(Benoît Claise) No Objection

Comment (2014-11-25 for -05)
No email
send info
No objection to the publication of the document, but please engage in the discussion, and clarify the text.

I don't understand what a "OS protocol" is, for example in section 5 "operational considerations"?
Is this a protocol that follows the OS definition, so that use a cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available?
Or is this one protocol that follows the principles in section 3?

The following point is key to me

 No misrepresentation of security:  Unauthenticated, encrypted
      communication must not be misrepresented to users or in
      application logs of non-interactive applications as equivalent to
      authenticated, encrypted communication.

I would go as far as telling that the communication characteristics (encrypted with authentication versus encrypted without authentication) must be clearly labeled to the end user, and not only in a log. Who reads log files, anyway?
That reminds me of the questions asked during one of the plenaries: are you in favor opportunistic encryption?
I bet that many people thought: well encryption is good, opportunistic has got a positive touch. So sure, I'm in favor.
If my mother would see "opportunistic encryption" when communicating with his bank application, I'm sure she would think: yep, everything is good!

(Spencer Dawkins) No Objection

Comment (2014-11-24 for -05)
No email
send info
The document is much improved in -05. Thank you for circling back around.

(Adrian Farrel) No Objection

Comment (2014-11-20 for -05)
No email
send info
Thanks for the extra cycle on this document. I think the added polish has made for a much better document.

(Brian Haberman) No Objection

(Joel Jaeggli) (was Discuss) No Objection

Comment (2014-11-25 for -05)
No email
send info
woud prefer


 However, when such attacks are employed pervasively in order to
 facilitate e,g, surveillance, this is probably detectable; hence,
 even in such scenarios OS protocols may provide a positive benefit.

but I've said my piece and I will trust the shepherding AD.

was:

hanging on Ted's point a bit. I might clear if he does.

If the use of what are essentially transparent proxies makes downgrade attacks, or effectively the removal of OE signaling entirely trivial then certain people will do that routinetly in order to support all sorts of ugly business models (the prexy is already there).

if you read about other cases that are effectively downgrades you can sort of imagine how insidious it is to think you reducing the visible surface area when in fact it's being stripped off again.

http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/

(Martin Stiemerling) No Objection