Ballot for draft-dukhovni-opportunistic-security-06

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.

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.

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.

Yes (for -04) Unknown

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.

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.

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.

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.

No Objection (for -04) Unknown

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.

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.

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

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

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