Subject: [saag] Need better opportunistic terminology

From: "Orit Levin (LCA)" <[email-masked]>
Date: Fri, 14 Mar 2014 22:56:29 +0000

Paul et al,
The proposal by Stephen F. makes sense to me, but I am having difficulty to understand why it doesn't work for you.

Based on the feedback on the list, "OE" is a loosely defined and broadly used term, while "OK", as was defined at the STRINT break-out session, is much more narrow in scope (while still application/protocol agnostic). There are additional to "OK" known techniques that, when being used in different combinations, all work towards the common goal of "activating encryption" under different tricky circumstances.

We do need to document the spirit of these techniques with their technical names (and potentially introduce new names where absolutely needed) as precisely as possible in an application-agnostic manner and also provide pointers to application specific mechanisms as the known examples. How is it different from what you are proposing?

Cheers,
Orit.

On Mar 13, 2014, at 8:10 AM, Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:

So if we had a draft that defined good/new/precise terms (e.g. OK),
and that included the above text in its intro, and that had some
text about the history (4322 etc), would that sound like a plan
to folks?

On Mar 13, 2014, at 9:05 AM, Paul Hoffman <paul.hoffman at vpnc.org>wrote:

Not to me. The "precise" terms such as OK is a distinction that will water down what we are trying to do. I would much prefer that we focus on the term people are already using, give it a general direction like Olle gave and a mediumly-precise definition that could be used across all protocols, and then give examples of its use in current usage (TLS and IPsec), saying that precise definitions might later be added in other RFCs. This will give people some possible excitement about doing the work instead of arguing about new terms.

On Mar 13, 2014, at 11:22 AM, Stephen Kent <kent at bbn.com> wrote:
Giving a "mediumly precise" definition followed by examples suggests that we're incapable of explaining what we're doing, which sends a bad message (maybe an accurate one, but still bad).

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Mar 2014 16:37:51 -0700

> The proposal by Stephen F. makes sense to me, but I am having difficulty to understand why it doesn't work for you.

I'll try not to reiterate directly, but:

- Using a new term like "opportunistic keying" leaves the listener asking what the difference is between it and the term they already know, so we are worse off

- As others have said, using "keying" is confusing because users don't care about the keying, they care about the encryption

- We cannot have one precise definition that covers protocols that do mutual authentication (like IPsec) and responder authentication (like TLS)

- Targeting protocol designers assumes that they are the ones driving implementations, but that hasn't been the case for opportunistic X for over a decade

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Mar 2014 16:42:44 -0700

> The proposal by Stephen F. makes sense to me, but I am having difficulty to understand why it doesn't work for you.

I'm not sure who specifically you're asking, but if it includes "et 
al.", for my part any proposal that uses "opportunistic" as primarily 
referring to the use of zero-ID (i.e., BTNS-style) approaches is broken.

There's absolutely nothing "opportunistic" in either the historical or 
grammatical sense about zero-ID.

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Mar 2014 19:10:09 -0500

On Fri, Mar 14, 2014 at 6:42 PM, Joe Touch <[email-masked]> wrote:
> I'm not sure who specifically you're asking, but if it includes "et al.",
> for my part any proposal that uses "opportunistic" as primarily referring to
> the use of zero-ID (i.e., BTNS-style) approaches is broken.
>

As far as English is concerned "opportunistic encryption" is
meaningful because the "opportunity" taken is that of denying passive
attackers their opportunity.  You do it when you can.

In the IPsec sense opportunistic means "you do it when you can
[authenticate the peer]", but the bracketed part really relates to
what we now call the PAD, and with the introduction of BTNS you can
always do that in a -weak, granted- sense.

So I'm of the opinion that "opportunistic encryption" can be
repurposed, though I won't claim that it won't cause confusion for at
least a few people...

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Mar 2014 17:16:14 -0700

> attackers their opportunity.  You do it when you can.

Again, it depends on what your focus is.

If it's the "opportunity" to fall-back, then it's about the fallback, 
not the zero-ID part. And fallback isn't opportunistic - it's just plain 
conservative.

If it's about the zero-ID part, there's no "opportunity" - it always works.

Opportunistic is either about pre-deployment or assuming something that 
*might not work* will, and trying that first. But that isn't part of the 
narrative I've heard about this mechanism at all.

> always do that in a -weak, granted- sense.

Sure.

> repurposed, though I won't claim that it won't cause confusion for at

I've already noted that if this is about PR, then there are far better 
terms.

There's no good reason for reusing a term with baggage incorrectly.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Mar 2014 12:00:57 -0400

On 03/14/2014 07:37 PM, Paul Hoffman wrote:

[Having been sick and reading these 200+ emails in a row - this PaulH's email seems the best starting point]

> - Using a new term like "opportunistic keying" leaves the listener asking what the difference is between it and the term they already know, so we are worse off

I agree. And they are not even interchangable. OE describes an endgoal, while OK describes a technical method. OK's goal could still be OE. Also, OK as an
acronym is really awkward.

To me, OE meant that if I am instructed to start a non-encrypted connection (say http://) that I am going to see if I can find a way to encrypt that connection
anyway. This could be mutual, single or un-authenticated. There is a clear element here of a fallback to plaintext, because the original job was to setup an
unencrypted connection. However, once we build infrastructure to support single or mutual authenticated OE, we create the problem of depending on its encryption
and not wanting it to fail back to cleartext. It is no longer opportunistic (rather opportune if my interpretation of English is correct)

> - As others have said, using "keying" is confusing because users don't care about the keying, they care about the encryption

Exactly, people seem to have forgotten that the term Opportunistic Encryption as popularised by FreeS/WAN was meant for endusers, not engineers.

> - We cannot have one precise definition that covers protocols that do mutual authentication (like IPsec) and responder authentication (like TLS)

I'm not sure if I agree here. If you see the term OE as a goal, not a method, than it does not matter whether the method uses mutual or responder authentication.

> - Targeting protocol designers assumes that they are the ones driving implementations, but that hasn't been the case for opportunistic X for over a decade

Times are changing?

We (libreswan) have also tried and failed to come up with a better term, and stuck with our internal terms for now (either NEW-OE or HDOE which is a honorary
reference to Hugh Daniel with a pun to HDTV)

Paul

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 18 Mar 2014 05:06:20 +0000

Paul,
You summarized clearly your position on why some of the specific names and protocol design techniques "don't work for you", but the question was different:
why the proposal for writing a document (or may be a wiki? :-) ) summarizing different "conceptual" approaches (loosely called O*) with their pros and cons is not a good idea. After all, the work in the IETF is contribution-driven...
Cheers,
Orit.

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 4:38 PM
> To: Orit Levin (LCA)
> Cc: [email-masked]
> Subject: Re: [saag] Need better opportunistic terminology
> 
> - Using a new term like "opportunistic keying" leaves the listener asking what the
> difference is between it and the term they already know, so we are worse off
> 
> - As others have said, using "keying" is confusing because users don't care about
> the keying, they care about the encryption
> 
> - We cannot have one precise definition that covers protocols that do mutual
> authentication (like IPsec) and responder authentication (like TLS)
> 
> - Targeting protocol designers assumes that they are the ones driving
> implementations, but that hasn't been the case for opportunistic X for over a
> decade
> 
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Mar 2014 07:52:17 -0700

> why the proposal for writing a document (or may be a wiki? :-) ) summarizing different "conceptual" approaches (loosely called O*) with their pros and cons is not a good idea. After all, the work i…

Ah, I missed the context. Stephen has made many proposals in this area, and I misunderstood the specific one you were referring to. I fully agree that we want a document summarizing the different approaches. Having that be a wiki will not be helpful to developers because edit wars can make things much worse. Listing the pros and cons will not be feasible if we expect the document to be a consensus document.

--Paul Hoffman