Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-06

[Ballot comment]
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/

[Ballot discuss]
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/

[Ballot comment]
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!

[Ballot discuss]
I'm generally in favor of this document, but there is something I feel needs to be discussed.

Section 4 describes the use of OE with SMTP, using STARTTLS.  However, it turns out that recently it's been discovered that this convention is under attack by some ISPs: https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

It's pretty clear that this downgrade attack is inexpensive to do, and it does exactly what a passive attacker would want: it defeats OE.  If OE is that easily subverted, what good is it?  I don't see the current document touching on this issue: instead, it simply accepts that this is true, but ignores it as an issue, asserting that MITM attacks are expensive, so OE helps.  I think the facts on the ground show that this is not so.

[Ballot comment]
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.

[Ballot discuss]
Well, either Stephen or I get to hold the DISCUSS, so I guess it's going to be me. As soon as this discussion is addressed, I'll switch to "Yes".

I disagree with the change to section 3 in the RFC Editor Note, as it does not represent IETF consensus. The current text as stated in the document is fine. I feel that any discussion of the "transition" from broken algorithms to good ones (not to mention the transition from cleartext to encrypted) is really orthogonal to this document: This document is saying that, if clear text is permitted, the protocol will work it's way up from clear text (if possible) to the best security it is able to achieve. That includes encryption using broken algorithms, which is still better than clear text to prevent a passive observer, who might not be willing to invest in saving the data and decrypting it later, from seeing the data. That we want to transition away from broken algorithms is as true as the fact that we want to transition away from clear text, but even the latter is not currently mentioned in the document, except by implication in the last paragraph of section 3.

I think a reasonable compromise is to add some discussion of broken algorithms to the last paragraph of section 3:

OLD
  Cleartext is supported for backwards compatibility with systems
  already deployed.  Even when cleartext needs to be supported,
  protocol designs based on Opportunistic Security prefer to encrypt,
  employing cleartext only with peers that do not appear to be
  encryption capable.
NEW
  The support of cleartext and the use of outdated algorithms, and
  especially broken algorithms, is for backwards compatibility with
  systems already deployed.  Protocol designs based on Opportunistic
  Security prefer to encrypt, and prefer to use the best available
  encryption algorithms available. OS protocols employ cleartext or
  broken encryption algorithms only with peers that do not appear to be
  capable of doing otherwise.

If Stephen or others insist that transition be mentioned, you could add a sentence to that paragraph, and I am likely willing to hold my nose:

                                The eventual desire is to transition
  away from cleartext and broken algorithms, and particularly for
  broken algorithms, it is highly desirable to remove such
  functionality from implementations.

But I really don't believe that such a sentence belongs in this document; if it does, it probably belongs in every Security Considerations section ever written that mentions the use of cleartext or encryption algorithms.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]

In reviewing this just before the end of IETF LC, there's one place
where I'd prefer a slightly different emphasis. I've run this by
Viktor and he however disagrees with the change so I'll leave it
for folks to comment and see what other IESG members think..
To be clear, I don't myself think the document needs to be
blocked to get this fixed, but I'd like it to be considered. And
I figure there are good arguments for both OLD and NEW
paragraphs below so I'm not saying that the NEW one below
is "right" and the OLD is "wrong" but I do think the NEW is
more consistent with what we want to see happen in future.
Others, (Viktor for example:-) can reasonably disagree.

OLD:

  With unauthenticated, encrypted communication, OS protocols may
  employ more liberal settings than would be best-practice when
  security is mandated by policy.  Some legacy systems support
  encryption, but implement only outdated algorithms or protocol
  versions.  Compatibility with these systems avoids the need to resort
  to cleartext fallback.

NEW:

  With unauthenticated, encrypted communication, OS protocols may
  employ more liberal settings than would be best-practice when
  security is mandated by policy.  Some legacy systems support
  encryption, but implement only outdated algorithms or protocol
  versions.  Compatibility with these systems avoids the need to resort
  to cleartext fallback. However, the use of "broken" algorithms,
  especially ones for which a ciphertext-only attack may be
  feasible in the near term, is not consistent with the OS
  approach. In such cases, avoiding the "broken" cipher, and
  falling back to cleartext is in fact the correct outcome, as
  recorded ciphertext for an algorithm with a feasible
  ciphertext-only attack is really the same as cleartext. That
  said, there may be cases where an implementation does negotiate
  use of such an algorithm for some (hopefully) short period
  with (hopefully) very few peers, while software and/or
  configurations are in the process of being updated, but this
  should be considered a failure (to update) and not as an
  acceptable outcome that is consistent with the OS approach.

IESG/Authors/WG Chairs:

IANA has reviewed draft-dukhovni-opportunistic-security-05, which is currently in Last Call, and has the following comments:

IANA notes that this document does not contain a standard IANA Considerations section.  We understand, however, that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

[Ballot comment]
My process-related DISCUSS points have been addressed by having the document revised and last called again.  I'm going to now ask the Secretariat to create a fresh ballot for the second telechat.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Opportunistic Security: Some Protection Most of the Time) to Informational RFC


The IESG is asking the community to re-review the new version of the
following document, as a result of the previous last call and IESG evaluation:

- 'Opportunistic Security: Some Protection Most of the Time'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

In particular, the IESG needs to know about substantive issues that have
not been addressed appropriately in this version.  Comments should clearly
mark each actionable issue that they are raising, and should clearly state
what action they are asking for.  Please suggest specific text, where that is
appropriate.

Abstract
  This document defines the concept "Opportunistic Security" in the
  context of communications protocols.  Protocol designs based on
  Opportunistic Security use encryption even when authentication is not
  available, and use authentication when possible, thereby removing
  barriers to the widespread use of encryption on the Internet.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/

No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
I had a full-out rant prepared about "tracking of issues" and such, but a night's sleep is a good thing. I've decided things are much simpler than that: There were substantive non-editorial changes between -03 and -04, substantive changes that *I* think have damaged the document in a substantive way, and changes about which the community does not have consensus. I believe there are things that need fixing, and therefore discussing. (For those playing at home, I'm hanging my hat on the last bullet of http://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc for this.) Let's start with the Intro:

  Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
  management approach.  With Opportunistic Security, one applies the
  tools at hand to mitigate the risks that can reasonably be addressed,
  and accepts the rest.
 
This is new text, not an editorial change. I find both of those sentences, and most of the other sentences in the Introduction, completely useless to the task of explaining what is important about OS, and unfortunately I think the Introduction as a whole now makes it *harder* for the reader to understand what OS is. I don't think there is community consensus that the new intro captures the intent. Most importantly:

  Thus, use of an OS protocol
  may yield communication that is authenticated and encrypted,
  unauthenticated but encrypted, or cleartext.
 
I find completely insidious because it damages the message of 1.2: Instead of a build up from a base of cleartext, which I absolutely agree is the way we should be thinking about security and is the essential bit of the OS model, this sentence and the one that follows it reinforce the notion that we start from fully authenticated communication and work our way down, precisely the notion that this document is supposed to be moving us away from. -03 made it clear to me that there was an order to things. It said that there was "stepping up from" cleartext. That text disappeared. In its place, there is the above text that apparently has the steps in the reverse order. The definition of the term in -04 doesn't even refer to the order. I do not remember seeing any discussion in which the participants came to consensus that this discussion of order should be removed.

The definition presented in this section also hides this important point.

The two essential bits of intro are the first paragraph of section 1.1 (which was once the first paragraph of the document) and the first two paragraphs of section 1.2, and we don't get to read them for another 6 to 15 paragraphs. They  need to be moved up and the rest of this new intro needs to be deleted.

In section 3:

  Coexist with local policy:  Local security policies preempt OS.
      Opportunistic security never displaces or preempts local policy.
      Many applications and types of data are too sensitive to use OS,
      and more traditional security designs are appropriate in such
      cases.

The title of section 3 is "Opportunistic Security Design Principles". Coexisting with local policy is not part of the OS design principle; it's a caveat to that design principle for times when you should *not* use OS. Again, this undermines the discussion of OS, and I do not believe that the community has consensus that the above is part of the OS design principle.

(One overarching point: Others have made comments with other serious problems that need fixing. That's fine. But if the result of addressing my comments or other folks's comments is to *add* more text, you've probably gotten it wrong. The main problem with -04 is the text that it added. Text needs to be deleted and simplified.)

This is important work and really needs to be done. In retrospect, I would have preferred to see this work done as a BCP in UTA or as an IAB document instead of simply a definition document. But we are where we are. We need to come to consensus on the text in here. We're not there yet.

[Ballot comment]
I did not have the time to dig through all of the IETF Last Call comments, so I am observing the process DISCUSSion with interest.

I do support the clarity issues raised by Adrian, Alissa, and Pete.

[Ballot discuss]
I had a full-out rant prepared about "tracking of issues" and such, but a night's sleep is a good thing. I've decided things are much simpler than that: There were substantive non-editorial changes between -03 and -04, substantive changes that *I* think have damaged the document in a substantive way, and changes about which the community does not have consensus. I believe there are things that need fixing, and therefore discussing. (For those playing at home, I'm hanging my hat on the last bullet of http://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc for this.) Let's start with the Intro:

  Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
  management approach.  With Opportunistic Security, one applies the
  tools at hand to mitigate the risks that can reasonably be addressed,
  and accepts the rest.
 
This is new text, not an editorial change. I find both of those sentences, and most of the other sentences in the Introduction, completely useless to the task of explaining what is important about OS, and unfortunately I think the Introduction as a whole now makes it *harder* for the reader to understand what OS is. I don't think there is community consensus that the new intro captures the intent. Most importantly:

  Thus, use of an OS protocol
  may yield communication that is authenticated and encrypted,
  unauthenticated but encrypted, or cleartext.
 
I find completely insidious because it damages the message of 1.2: Instead of a build up from a base of cleartext, which I absolutely agree is the way we should be thinking about security and is the essential bit of the OS model, this sentence and the one that follows it reinforce the notion that we start from fully authenticated communication and work our way down, precisely the notion that this document is supposed to be moving us away from.

The definition presented in this section also hides this important point.

The two essential bits of intro are the first paragraph of section 1.1 (which was once the first paragraph of the document) and the first two paragraphs of section 1.2, and we don't get to read them for another 6 to 15 paragraphs. They  need to be moved up and the rest of this new intro needs to be deleted.

In section 3:

  Coexist with local policy:  Local security policies preempt OS.
      Opportunistic security never displaces or preempts local policy.
      Many applications and types of data are too sensitive to use OS,
      and more traditional security designs are appropriate in such
      cases.

The title of section 3 is "Opportunistic Security Design Principles". Coexisting with local policy is not part of the OS design principle; it's a caveat to that design principle for times when you should *not* use OS. Again, this undermines the discussion of OS, and I do not believe that the community has consensus that the above is part of the OS design principle.

(One overarching point: Others have made comments with other serious problems that need fixing. That's fine. But if the result of addressing my comments or other folks's comments is to *add* more text, you've probably gotten it wrong. The main problem with -04 is the text that it added. Text needs to be deleted and simplified.)

This is important work and really needs to be done. In retrospect, I would have preferred to see this work done as a BCP in UTA or as an IAB document instead of simply a definition document. But we are where we are. We need to come to consensus on the text in here. We're not there yet.

[Ballot discuss]
I think this document needs to state explicitly that opportunistic security is _not_ appropriate in the same set of applications as mandatory security.  E.g., we never want "opportunistic security" when connecting to the bank, or doing a credit card transaction.  We want mandatory security.  I think that is so obvious to the security folks that nobody thought to mention it, but it must be stated in large friendly letters both in the introduction and in the security considerations section, because this document will be read by non-security-geeks.  You should also advise that documents that describe implementations of opportunistic security should mention this in _their_ security considerations section.  An opportunistically secure protocol that can be MiTM'd to look secure on the server end whilst being in cleartext on the client end would be disastrous in such contexts.

[Ballot comment]
Aside from issues of accuracy, the choice of the phrase "opportunistic security" is unfortunate because it leads to abbreviation as "OS" which is a well known acronym for "operating system," and a slightly less frequently used acronym for "open source."  I'm not raising this as a strong objection, because I know this topic was hotly debated during IETF last call, but the arguments I saw during the debate that it's just not that important and can't be fixed anyway fall flat for me because of this problem.  Every time I see "OS support" or something similar in the text, I read "operating system support," not "opportunistic encryption support."  If you are going to use this term, I think you should get over the wish for brevity and just spell it out.  I would call it "opportunistic protection" or something like that to get a better acronym.  Nobody's going to read "OP support" as "original poster support".

In section 5:

  When protection only against passive attacks is negotiated over a
  channel vulnerable to active downgrade attacks, and the use of
  encryption fails, a protocol might elect non-intrusive fallback to
  cleartext.  An active attacker could equally have suppressed the use
  of encryption during negotiation, so failure to encrypt may be more
  often a symptom of an interoperability problem than an active attack.

The last sentence doesn't make sense—the first half of the statement doesn't actually imply the second half as a conclusion, as the "so" in the middle would suggest.  It implies the opposite.  I don't think you are saying anything wrong here, but you need to clean this text up, because as written it doesn't make sense.

When the DISCUSS is cleared, I will change this to a no objection, but while I don't necessarily agree with Barry's remedy for the DISCUSS, I do agree with the general thrust of his DISCUSS.

[Ballot comment]
First, I am quite supportive of a revision of this document going forward.  It provides a pragmatic and useful mindset towards mitigating pervasive monitoring.

However, I do support Barry's Discuss.  I have not followed all of the discussion on the IETF list about the draft, but enough to feel uncomfortable about the interactions.  There can certainly be rough consensus but the reaction seems to be more about transparency of what and why things were changes. 

Secondly, I am not fond of the term "Opportunistic Security" as compared to "Opportunistic Encryption" if encryption is really all that is meant.  For instance, does OS have the ability to improve over clear-text to prevent replay attacks?  That's something that encryption alone doesn't necessarily provide; of course, it can also be protocol-specific.  IF this is about OS and not OE, I would find it useful to be clearer about the dimensions/aspects of security that can be opportunistic.  It definitely reads like this is only about opportunistic encryption and nothing else.

[Ballot discuss]
Thanks to everyone who worked on this document. I think it is a helpful contribution.

On process, prior to taking a deep dive into the LC mailing list traffic and talking with the AD, shepherd, and author, I was originally skeptical about whether this document had achieved rough consensus and whether IETF process had been followed effectively. After having taken those steps, I am convinced that both are true.

I also now understand why the term "opportunistic security" was chosen and believe there is rough consensus in support of using that term.

However, for a document that is quite short and a concept that is fairly straightforward, I find this document really difficult to understand in places. I've listed the bits that are so ambiguous that I think readers will not understand them as DISCUSS points and other comments as COMMENT points.

DISCUSS:

o Section 1:
"For a particular protocol or application, if and when all but a
  negligible fraction of peers support encryption, the baseline
  security may be raised from cleartext to always require encryption.
  Similarly, once support for authentication is near-universal, the
  baseline may be raised to always require authentication."

I agree with Adrian that it is unclear what this means. And in fact it seems to contradict other language in the document by assuming that a protocol has one mode of operation for *all* peers. I thought one of the goals of OS was that within any single protocol interaction or within any single group of peers, the level of encryption used could be negotiated up to the lowest common denominator among the peers. Perhaps this would be clearer if it emphasized that the default mode for a particular protocol or application might be chosen to be cleartext, unauthenticated encryption, or authenticated encryption, with the ability for peers to negotiate up if they are capable.


o Section 1:
"In essence, OS is employed when one might otherwise settle for cleartext
  (or the minimum protection possible if the protocol is always
  encrypted)."

I don't understand the parenthetical, either in substance or grammar.


o Section 1:
"For example, a policy might require authenticated, encrypted
  communication, in contrast to the default OS security policy."

This sentence presents another reason why the previous paragraph does not make sense. The previous paragraph seems to say that in some cases, the default OS security policy could be to use authenticated encryption. In those cases, this sentence is not correct.


o Section 1.2:
I find the document's guidance about the extent to which OS protocols "work behind the scenes" to be confusing. There is this text in this section:

"OS protocols work
  transparently behind the scenes, without disrupting communication.

  When less than complete protection is negotiated, there is no need to
  prompt the user with "your security may be degraded, please click OK"
  dialogs.  The negotiated protection is as good as can be expected.
  Even if not comprehensive, it is often better than the traditional
  outcome of either "no protection" or "communications failure"."

And then in Section 3 there is this:

"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."

The bit about working "behind the scenes" and not prompting the user seems to me to be distinct from the issue of misrepresenting security. That is, (1) whether the user is proactively informed of the extent to which his communications are protected, (2) whether the user is able to find out about that protection on his own, and (3) whether the information provided to the user about that protection is accurate are three separate questions. I find that Section 1.2 argues against (1), although this is not elevated to the level of a "design principle" as it is not included in Section 3. Section 3 argues in favor of (3) -- providing accurate information -- and includes that as a design principle. I believe the document is silent about (2).

I get the sense that (1) is viewed by people who worked on this document as an important by-product of wider deployment of OS, so I would have expected support for it to be more explicit in the document, rather than somewhat latent as it is. If there were a fuller discussion of (1), I would also expect (2) to be addressed, as it is natural to ask just how "behind the scenes" OS protocols are expected to be (as Adrian pointed out). This seems like a fairly significant gap in the document.

[Ballot comment]
o Section 1:
s/For authentication based on peer capabilities to protect
  against MiTM attacks/For authentication based on peer capabilities to be able to protect against MiTM attacks/

(FWIW, the above makes more sense to me than Adrian's suggested edit to the same sentence.)


o Section 1.1:
General comment: It is really unclear what the point of this section is and why this set of paragraphs is strung together as one section. I would suggest adding an opening paragraph along the lines of "This section provides some background about historic and current challenges associated with the use of encryption on the Internet, illustrated using discussion of the Web PKI."


o Section 1.1:
s/With so many certification authorities, which not everyone is willing to trust,
  the communicating parties don't always agree on a mutually trusted
  CA./With so many certification authorities, all of which are not trusted by all entities, the communicating parties don't always agree on a mutually trusted
  CA./


o Section 1.1:
"In interactive
  applications, security warnings are all too frequent, and end-users
  learn to actively ignore security problems"

This point is orthogonal to the rest of the paragraph to which it is attached. The fact that choices were made to pop security warnings was separate from other choices made about the web PKI. It doesn't quite make sense to me why this is mushed together with a paragraph about "cost and management burdens."


o Section 1.1:
"For encryption to be used more broadly, authentication needs to be
  optional.  The use of encryption defends against pervasive monitoring
  and other passive attacks (which are employed not only by nation
  states).  Even unauthenticated, encrypted communication (defined
  below) is preferable to cleartext."

This seems like it should be the first paragraph of Section 1.2. It is rather out of place in Section 1.2.


o Section 3:
"OS offers an incremental path to authenticated, encrypted communication in the
  future, as suitable authentication technologies are deployed."

As in Section 1, this text seems to assume one mode of operation for a particular protocol. What about protocols that can already support authenticated encryption? Doesn't OS offer an incremental path towards using that mode right now, not in the future, for peers that already support it?


o Section 3:
s/Communication should generally
      be at least encrypted./At a minimum, communication should generally
      be encrypted without authentication./

(I think this was the intention here, although I'm not completely sure what "at least" means.)

[Ballot discuss]
This DISCUSS is on process grounds; I think we have two serious process issues that prevent our claiming that we have rough consensus on the document.

1. The community reviewed and commented on version -03.  The IESG is being asked to approve version -04, and is being told there is rough consensus on its content.  And yet vesion -04 is essentially a complete rewrite of the document.  I understand the assertion that the changes are "just editorial", but that doesn't help: the fact is that the community has *not* reviewed anything close to the version we're being asked to approve.  It would be a terrible precedent to say that a document could be rewritten after last call and sent to the IESG for approval that way.

I believe that, despite any concern about the usefulness of another last call, this document must get another last call in its current form.  To do otherwise would be to trash our rough consensus process.

2. I think the way the document editing was done, and the way the comments were (and were not) responded to was poor, and calls into question what does and doesn't have rough consensus (certainly according to RFC 7282).  There were substantive comments that were made that were not explicitly discussed; those comments were then declared "in the rough".  I don't believe such declaration can be made purely on the basis of lack of visible support, with no actual discussion or refutation.  Dave Crocker and Stephen Kent have both brought up some such issues.

I think that re-last-call needs to be accompanied by instructions for people to raise issues that they think they raised before that were not properly discussed, so that there is a chance for them to *be* discussed and, perhaps, for them to be properly declared in the rough once there's real discussion about them.  I know some people will think this is a PitA at best, but it should have been done before.  An issue tracker, carefully managed, would have been an appropriate tool for a document with this much discussion -- and this much diverse discussion.

[Ballot comment]
I also have two major issues with the document, but note that these are *not* un the DISCUSS portion.  Consider this to be strong input, but not part of the blocking process:

I'm quite unhappy with the decision to go with "Opportunistic Security" here (rather than "Opportunistic Encryption", since it *is* talking about encryption, or rather than finding another appropriately focused term if there are good reasons not to use "OE").  My sense is that the reasons to use "OS" amount to marketing, but there are solid reasons to use "Encryption" when encryption is central, and not to use the overly broad term "Security" for something that is not actually meant to be broad.

I don't like the organization of the document; I don't think it's well written and sufficiently coherent.  I know this is vague, but short of having me do yet another rewrite I don't know how to be more specific.  The general thing is that topics seem to drift in and out, and the whole document doesn't read as a clear path from one idea, through another, to a set of conclusions.

[Ballot comment]
I'm balloting "No Objection" primarily on Stephen's assurance that the text changes in this version of the draft are editorial in nature, and I accept his assertion that continued discussion is unlikely to result in improvements to the document.

I suspect that continued discussion wouldn't result in the Internet being more resistant to passive monitoring, either, although I'm not one who has enough security clue to assert that in a meaningful way.

I agree with the vast majority of Adrian's detailed comments, and think the document would be improved by considering them.

I agree with Stephen's statement that publishing this document in the Independent Stream is unlikely to be helpful.

[Ballot comment]
I am not done with my review, but in the meanwhile I have question:

How does this draft related to the old Better-Than-Nothing Security (btns) working group [1] and their output?

[1] http://www.ietf.org/wg/concluded/btns.html

[Ballot comment]
It is good and helpful, in my opinion, for the IETF to give an
explanation of Opportunistic Security and advocate its use.

The data tracker currently shows "Consensus: Unknown" and I think that
is actually a fair representation of the state of affairs. It is,
however, not a state in which we can publish an IETF Stream RFC.

Having read a lot of the email thread resulting from IETF last call
and looked at the changes in the last few revisions I conclude that
there is general support for the technical content of this document,
but that there are a good number of unaddressed issues with the
development and presentation of that content. It may be true that
addressing those points would not make a substantive difference to the
technical ideas in the document, but that does not mean that the
document would not be improved by attentive work.

At the moment I am sufficiently unclear on the consensus for the 
publication of this document to be either able to place a Discuss on
the absence of consensus or to be able to ballot No Objection. Hence
this Abstain.

I wish more work had been / would be done to build consensus or that
the document was advanced either as "published without consensus" or
on the Independent Stream.

==========

I have spent too long hanging around with sales staff and this has made
me over-sensitive to the use of language that smells of marketing. I
apologise for any over-reaction on my part, but I presume that the
purpose of publishing the document is to deliver a useful and clear
statement, so I think that polishing might not be a waste of time.
If I was entering this Comment as part of IETF last call I would expect
a reasonable discussion of the cost/benefit of not changing the text to
address my thoughts. But, obviously, I am not. Furthermore, I am not
raising these points as Discusses so you can work through them with your
shepherding AD and ignore me if you think that I am wrong or that the
effort is not worth the results.

- - - -

Abstract...

  Protocol designs based on
  Opportunistic Security remove barriers to the widespread use of
  encryption on the Internet by using encryption even when
  authentication is not available

So, this says "remove barriers to X by using X".
I think there is probably something additional you need to say before
this sentence. For example, "Most approaches to the use of encryption
on the Internet depend on the use authentication to foo.  This makes
encryption unattractive because bar."

---

Introduction

  Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
  management approach.

"pragmatic" is redundant in the description of "risk management".

"...approach" to what?

---

Introduction

  With Opportunistic Security, one applies the
  tools at hand

This implies to me that no changes or modifications to protocols are
needed to achieve OS. I don't believe that is true.

---

The definition presented in Section 1 is OK as far as it goes, but
isn't it missing also the existence of the capability in the protocol
itself?

Isn't a fundamental part of OS that the operation of encryption can be
without manual keying and therefore without the configuration of
security adjacencies? I think that what is missing from this document,
and possibly from this definition, is a description of why security
(specifically encryption) is not widely used in the Internet today.

It is also a little questionable to me what is "opportunistic" in this
definition. You seem to be defining "Best Effort Security". Hey-ho. It's
only a name, and just words.

---

Introduction

  Since encryption alone mitigates only
  passive attacks, this risk is consistent with the expected level of
  protection.

"Since encryption alone..." can be read two ways:
1. Only encryption can do this
2. Using only encryption with nothing else can only go so far
I suggest you make some clarification to remove this ambiguity.

"this risk is consistent with the expected..." I don't think so. I think
the risk defines the level of protection that can be delivered.
Expectations need to be set and this document can do so by describing
the risks and the likelihoods.

---

  For authentication based on peer capabilities to protect
  against MiTM attacks, capability advertisements need to be over an
  out-of-band authenticated channel that is itself resistant to MiTM
  attack.

I had a lot of trouble parsing the first clause in this sentence. Is it
the peer capabilities that can protect against MiTM attacks? Or is it
the authentication that does the protection? I think you are saying...
  In order that authentication mechanisms can protect against active
  MiTM attacks on capability exchanges between peers, those capability
  exchanges need to be performed over...

But why are you insistent on an out-of-band channel? Surely any
authenticated channel that is resistant to MiTM attacks will be good
enough?

---

  OS protocols will attempt to establish encrypted communication
  whenever both parties are capable of such, and authenticated
  communication if that is also possible.  This last outcome will
  occur if not all parties to a communication support encryption (or if
  an active attack makes it appear that this is the case).

Is there any element of choice here? The text says not.

---

  For a particular protocol or application, if and when all but a
  negligible fraction of peers support encryption, the baseline
  security may be raised from cleartext to always require encryption.
  Similarly, once support for authentication is near-universal, the
  baseline may be raised to always require authentication.

I don't know what this means!
I think it says that at some moment in time the Internet Police will
ban the use of unencrypted use of a protocol or application. Or maybe
it says that new implementations can require encryption and refuse to
operate with legacy implementations. Or perhaps you mean that the
default behaviour should be to try for encryption. Or perhaps you are
just talking about what the user can expect.

---

The abbreviation "CA" is used without expansion.

---

Section 1.1

  DNSSEC is not
  sufficiently widely deployed to allow DANE to satisfy the Internet-
  wide, any-to-any authentication requirement noted above.

Did I miss the any-to-any requirement? I looked back but didn't find it.

---

Section 1.1 makes a good case about encryption without authentication
being of value. But this seems to be making a different (although
equally valid) case from the basis of the document that is about OS.
This comes back to the "opportunistic" versus "best effort" thing.

---

Section 1.1

  The use of encryption defends against pervasive monitoring
  and other passive attacks (which are employed not only by nation
  states).

The parenthesised text can probably be dropped. It is not a discussion
you need to have here.

---

Section 1.1

  For some applications or protocols the set of potential peers
  includes a long tail of implementations that support only cleartext.

On third reading I got what the "long tail" refers to. How about...

  For some applications or protocols it is anticipated that the set of
  potential peers that only support cleartext will persist for a long
  time.

---

Section 1.2

  This document proposes a change of perspective.

Why is it a proposal in what you plan to publish as an IETF Consensus
RFC? I assume you don't really want this to be Experimental.

---

I am fine with the concept of opportunistic security and like it. But
I think I reject the hypothesis in Section 1.2 that the old world is
"expect full security and notify when not achieved" and that the new
world is "expect no security and get the best you can." I think the new
world is / should be "configure the level of security that is acceptable
to you, get at least that security and maybe better, or get notified if
it is not as good." This is more subtle than your proposal but involves
the user in a way that I think is important. That is, if a user desires
security, it is not enough to say "the protocol is designed to get as
much security as it can" - the user actually wants to know if the
security level is low, and may want no traffic if the security level is
too low.

This does not reject the idea of OS, but merely the choice presented in
Section 1.2.

In fact, Section 3 makes these trade-offs pretty clear, so I think
that all that is needed is to moderate the language in this section.
(Although Section 5 seems to favour some sort of autonomy within the
protocol or protocol implementation such that various fallbacks might
"just happen".)

---

Section 3

  OS provides a near-term approach to counter passive attacks by
  removing barriers to the widespread use of encryption.

This is probably true, and definitely a motivation, and not a Design
Principle. Not appropriate in this section of the document.

---

Section 3

I had to read "Emphasize enabling communication" and the following text
a couple of time to extract the right meaning. What you have has two
different meanings, and you mean "enablement of" (otherwise "an
enabling communication" is inferred).

---

Section 5 has...

  The choice
  to implement or enable fallback should only be made in response to
  significant operational obstacles.

...but no mention of who makes the choice for enablement. I think you
need that such fallback is never a default action and always requires
operator/user intervention since forcing such a fallback sounds like an
effective attack.

---

One point that I would possibly have entered as a Discuss were I not
Abstaining is that I am surprised that there is no discussion of
mechanisms that can be used to detect MiTM attacks on unauthenticated
encryption key exchanges. Detection is a useful tool since, while it
can't help with protection of data, it can at least warn the user to
stop relying on the security of the data channel.

[Ballot comment]
Thanks for your work on this draft, Viktor.  I have some suggested text to update a few sentences that I would like you to consider.

Bottom of page 2, suggested text edit to clarify meaning on the last sentence:
Change from:
  Protection against active attacks requires authentication.  The
  ability to authenticate any potential peer on the Internet requires
  an authentication mechanism that encompasses all such peers.  No IETF
  standards for authentication meet this requirement.

To:
  Protection against active attacks requires authentication.  The
  ability to authenticate any potential peer on the Internet requires
  an authentication mechanism that encompasses all such peers.  No IETF
  standards for authentication scales as needed and have been deployed
  widely enough to meet this requirement.

on page 3, I recommend updates to the 2nd and third sentences to more correctly describe the issue with CAs (it's not just one that we all need to trust)
change from:
  With so many
  certification authorities, which not everyone is willing to trust,
  the communicating parties don't always agree on a mutually trusted
  CA.  Without a mutually trusted CA, authentication fails, leading to
  communications failure in protocols that mandate authentication.

To:
    With so many
    certification authorities, which not everyone is willing to trust,
    the communicating parties don't always agree on a mutually trusted
    CA from their respective lists of trusted CAs.
    Without a mutually trusted CA, authentication fails, leading to
    communications failure in protocols that mandate authentication.

For the terminology section, I do like that OS is defined in the introduction and saw that many provided feedback asking for that to be done.  Thanks for making the change.  Should there also be a pointer from the terminology section back to section 1 for the definition of OS?

Security Considerations section:
I'd be happier if the first sentence had a pointer to section 3 so there is context to the statement.

Perhaps change from:
  OS supports communication that is authenticated and encrypted,
  unauthenticated and encrypted, or cleartext.
To:
  OS supports communication that is authenticated and encrypted,
  unauthenticated and encrypted, or cleartext (see Section 3. Opportunistic Security Design Principles).


Or something similar just to make the point that the purpose of OS is to offer another option between authenticated and encrypted and cleartext as opposed to just saying they are all supported.


Side note:  Thank you for your work on this draft and partaking in the many discussion threads about the contents of the draft.  The discussion on this draft were heated at times and I would have preferred to see more detailed responses to the list on *some* of the threads, those which offered direct suggestions.  I think that could have helped the overall tone and interactions for a least a few of the commenters.  Some reviewers put in considerable time helping to revise the draft, Steve Kent in particular, and that is very much appreciated. 

I do think the draft is good enough, but I would like to see my comments addressed to clarify a few more points.

[Ballot comment]
I'm going to press "defer" on this, because I have concerns about the consensus here, and because of the IGF meeting I won't have time to chase it down and satisfy myself.

Primary among my concerns is this: really, none of us would be happy accepting a document with *that* much text changing after last call, without a second last call.  I know you think it's just editorial stuff, and I know you think another last call will just bring up all the same issues that got set aside last time (legitimately or not).  And, yet, c'mon: can you honestly say that you'd be happy if another document, one that you weren't involved in, was essentially re-written after last call?

1. Summary

This is the shepherd writeup for draft-dukhovni-opportunistic-security-04. Paul Hoffman is the
document shepherd, and Stephen Farrell is the responsible Area Director.

The document defines the term "Opportunistic Security" and gives the design philosophy and
principles behind it. Using opportunistic security leads to the use of encryption in situations
which would otherwise use unencrypted communication. This document does not define a protocol, and
does not give a single method for attaining opportunistic security. The publication type is
Informational, which is appropriate for this type of overview publication.


2. Review and Consensus

The document and its predecessors were discussed with great gusto over many months on the SAAG
mailing list, in the UTA WG, and at two IETF meetings. There is a great deal of interest in having a
common set of definitions for the ideas related ot opportunistic security, even where there might be
disagreement about where it should and should not be used.

The IETF Last Call on the -03 draft produced a lot of suggestions for major improvements to the
language in the draft, and the author did a significant revision based on them, all without changing
the design philosophy. There are probably still some people who think that the wording is not what
they would want, and some who think that the whole idea is a bad one, but there was rough consensus
that the document was useful and should be published.

The document has had more review, and ended up getting stronger consensus for the eventual
definition, than the products of many security WGs. Because this document does not define how to
implement opportunistic security, there is some disagreement about its applicability to existing and
future IETF protocols, but there was strong agreement that the definition was good enough for many
protocols.


3. Intellectual Property

The author has stated that his direct, personal knowledge of any IPR related to this document (that
is: none) has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

None, really.

IESG/Author,

IANA has revieweddraft-dukhovni-opportunistic-security-01, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

1. Summary

This is the shepherd writeup for draft-dukhovni-opportunistic-security-01. Paul Hoffman is the document shepherd, and Stephen Farrell is the responsible Area Director.

The document defines the term "opportunistic security" and gives a concise design philosophy to support it. Using opportunistic security leads to the use of encryption in situations which would otherwise use unencrypted communication. This document does not define a protocol or a particular method for attaining opportunistic security, and the publication type is Informational.


2. Review and Consensus

The document and its predecessors were discussed with great gusto over many months on the SAAG mailing list, in the UTA WG, and at two IETF meetings. There is a great deal of interest in having a common set of definitions for the ideas related ot opportunistic security, even where there might be disagreement about where it should and should not be used.

The document has had more review, and ended up getting stronger consensus for the eventual definition, than the products of many security WGs. Because this document does not define how to implement opportunistic security, there is some disagreement about its applicability to existing and future IETF protocols, but there was strong agreement that the definition was good enough for many protocols.


3. Intellectual Property

The author has stated that his direct, personal knowledge of any IPR related to this document (that is: none) has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

None, really.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Opportunistic Security: some protection most of the time) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Opportunistic Security: some protection most of the time'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines the term "opportunistic security".  In contrast to
  the established approach of delivering strong protection some of the
  time, opportunistic security strives to deliver at least some
  protection most of the time.  The primary goal is therefore broad
  interoperability, with security policy tailored to the capabilities
  of peer systems.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/


No IPR declarations have been submitted directly on this I-D.

This document and a predecessor have been the subject of discussion
on the saag mailing list. [1]

    [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html