Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-06
Discuss
Yes
(Stephen Farrell)
No Objection
(Richard Barnes)
Abstain
No Record
Note: This ballot was opened for revision 04 and is now closed.
Alissa Cooper Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-09-17 for -04)
Unknown
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.
Pete Resnick Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-09-18 for -04)
Unknown
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.
Ted Lemon Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-09-18 for -04)
Unknown
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.
Stephen Farrell Former IESG member
Yes
Yes
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(2014-09-17 for -04)
Unknown
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.
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-11-05 for -05)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(2014-09-18 for -04)
Unknown
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.
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-09-15 for -04)
Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-09-16 for -04)
Unknown
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.
Adrian Farrel Former IESG member
Abstain
Abstain
(2014-09-15 for -04)
Unknown
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.
Martin Stiemerling Former IESG member
No Record
No Record
(2014-09-16 for -04)
Unknown
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