Subject: [saag] better ** terminology

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2014 18:04:34 -0400

I have just posted an I-D that does a few things:

     - it proposes yet another term for the subject of our protracted 
terminology discussion
     - it defines what that term means, based on a STRINT workshop 
breakout group
     - it argues why "opportunistic encryption" is a poor terminology choice
       for what we want to describe
     - it examines some other aspects of terminology for key management
       that yields authenticated, anonymous, or pseudonymous communications

I extracted this text form a bigger document, and made changes based on 
the debate
that has been taking place on SAAG, replacing my preferred 
"opportunistic keying"
with a term that seems tailor made to the problem we're addressing :-).

https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/

Steve

---

From: Paul Lambert <[email-masked]>
Date: Tue, 18 Mar 2014 15:54:21 -0700

>I have just posted an I-D that does a few things:

Nice well crafted draft/analysis of terms.

Comments on :

>1.  It is invisible to users (so that they do not become confused by
     the set of security services they are being offered).
...
>4.  Detection of a man-in-the-middle (MiTM) attacks is a desired,
>  thought not mandatory, feature.
>
>5.  Authentication is a desired, thought not mandatory, feature.

We need to be careful with the combination of Œinvisible¹ to user
and optional authentication.  It would be desirable
to have recommendations that users be able to determine the type of
security that they have for a particular connection.  This
Is a terminolgy draft, so this may or may not be the right place.

There is also a statefulness in the  models (like LoF and TOFU)
that is not fully captured.  A connection that starts as
LoF could become strongly authenticated later through an
out-of-band channel to become Œauthenticated¹.

Paul

>_______________________________________________
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Mar 2014 11:19:48 -0400

Paul,

> Nice well crafted draft/analysis of terms.
thanks.
> Is a terminolgy draft, so this may or may not be the right place.
I was reporting what appeared to be the consensus of the STRINT
workshop breakout session, wrt UIs and PE. Folks need to discuss
this and come to agreement. I see merit in hiding PE from users
so that that don't become confused, but ...
> out-of-band channel to become Œauthenticated¹.
Agreed. Additional material discussing LoF/TOFU is needed.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Mar 2014 08:50:18 -0700

On Mar 18, 2014, at 3:04 PM, Stephen Kent <[email-masked]> wrote:

>    - it proposes yet another term for the subject of our protracted terminology discussion

The protracted terminology discussion on SAAG seemed to end with more people wanting to use "opportunistic encryption" with a new definition rather than making up a new term.

>    - it defines what that term means, based on a STRINT workshop breakout group

I do like most of the seven points in section 1; they capture what I think is a likely consensus of the discussion so far.

>      for what we want to describe

...at which point it goes off the rails. It tries too hard to make the old term have an important meaning. That discussion also skips over some of the obvious flaws with your new term. For example, there is no expectation that the adoption of PE will be high enough to justify the term "pervasive". That kind of overstated marketing is like naming a protocol "simple". :-)

>      that yields authenticated, anonymous, or pseudonymous communications

No offense, but most of that is just selling well past the agreement. Many of the definitions in Section 2 are not universally agreed on, and trying to force those terms down people's throats is likely to cause the important stuff in the definition to be ignored.

> I extracted this text form a bigger document, and made changes based on the debate
> that has been taking place on SAAG, replacing my preferred "opportunistic keying"

Making the jacket to be five sizes too large just in case we gain a lot of weight is not necessarily good tailoring. Please strongly consider using the term that we had previously agreed on.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Mar 2014 15:55:35 +0000

On Wed, Mar 19, 2014 at 11:19:48AM -0400, Stephen Kent wrote:

> >out-of-band channel to become ?authenticated?.
>

Would it also be appropriate to briefly discuss the use of DANE to
harden PE against MITM downgrade attacks?  As in the DANE SMTP and
SRV drafts, the idea is that when a server has associated TLSA RRs,
encryption (via TLS) becomes mandatory, and when some of the TLSA
RRs are "usable", authentication is also mandatory.  The result is
I think not too dissimilar from the original OE in IPSEC, in that
what you get is an authenticated connection without prior bilateral
arrangement (fax effect and all that).

[ Does the PE draft inspire a better name for "opportunistic DANE
  TLS", or is that name about right. ]

-- 
	Viktor.

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2014 09:59:04 -0700

Steve,

Interesting document.

It's further worth noting in this document that RFC4322 itself indicates 
a clear distinction between anonymous keying and OE:

    Opportunistic encryption creates tunnels between nodes that are
    essentially strangers.  This is done without any prior bilateral
    arrangement.  Therefore, there is the difficult question of how one
    knows to whom one is talking.

    One possible answer is that since no useful authentication can be
    done, none should be tried.  This mode of operation is named
    "anonymous encryption".  An active man-in-the-middle attack can be
    used to thwart the privacy of this type of communication.  Without
    peer authentication, there is no way to prevent this kind of attack.

    Although it is a useful mode, anonymous encryption is not the goal of
    this project.  Simpler methods are available that can achieve
    anonymous encryption only, but authentication of the peer is a
    desirable goal.  Authentication of the peer is achieved through key
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    distribution in DNS, leveraging upon the authentication of the DNS in
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    DNSSEC.
    ^^^^^^

This further underscores that OE is *not* unauthenticated keying. In 
contrast, unauthenticated keying was the primary goal of BTNS (RFC 
5387), which thus should be discussed in this doc as well:

    To improve the situation, one could either reduce the hurdles to
    obtain and configure authentication information or remove the
    requirement for authentication in IPsec.  The latter approach is the
    core idea of BTNS, which provides anonymous (unauthenticated) keying
    for IPsec to create security associations (SAs) with peers that do
    not possess requisite authentication credentials.

and includes:

    BTNS employs a weaker notion of authenticated identity by comparison
    to most authentication protocols; this weaker notion is bootstrapped
    from the security association itself.  This notion, called
    "continuity of association", doesn't mean "Bill Smith" or "owner of
    shared secret X2YQ", but means "the entity with which I have been
    communicating on connection #23".

Joe

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Mar 2014 12:24:07 -0500

> Agreed. Additional material discussing LoF/TOFU is needed.

Oh man, one term we most certainly can't use is OA == opportunistic
authentication...  Too close to OAuth.

Anyways, there's a spectrum of security.  The key is to describe that
spectrum appropriately -- appropriately for _typical users_ because
whatever terminology we settle on will almost certainly find itself
into mass consumer consciousness.

Alternatively we need a terminology that is explicitly chosen such
that it would not be used in marketing materials nor otherwise be
likely to come to the attention of mass consumers.

The main problem is that explaining MITM attacks is not easy, and yet
we need MITM attack resistance/detection in many, many cases (e.g.,
coffee shop wifi).

At one end of the spectrum we have:

 - no real security

progressing through:

 - security against passive attacks
 - LoF/TOFU: some security against active attacks if you remember keys
for long (i.e., force an MITM to be there the first time and always)
 - security against passive and active criminal attackers
(authentication + encryption)

with users _today_ only really being aware of the last one (security
against criminal attackers).

(I say "criminal" to distinguish from LEO/TLA agency types.)

Then we have:

 - security against passive and active foreign TLA agencies (difficult)
 - security against passive and active LEO/TLA agenciess whose
jurisdiction you're in (exceedingly difficult / impossible at the
limit, but possible when you're not interesting)

On a different axis: security against traffic analysis (very, very
hard -- the most difficult).

For mass consumption we don't need the last three, but we do need to
cover these three options:

 - security against passive attacks
 - LoF/TOFU: some security against active attacks if you remember keys
for long (i.e., force an MITM to be there the first time and always)
 - security against passive and active criminal attackers
(authentication + encryption)

and I believe we need terminology that mass consumers can understand.

For those three items I find "opportunistic" or "qualified" to be
really good terms.  I particularly like "qualified".

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Mar 2014 10:37:22 -0700

On Mar 19, 2014, at 9:59 AM, Joe Touch <[email-masked]> wrote:

> This further underscores that OE is *not* unauthenticated keying.

It underscored that OE *as defined in RFC 4322* is not unauthenticated keying. As many people here have said repeatedly, we don't care about what the authors of that document said: the term has be reappropriated to mean best-effort keying triggered without the user's knowledge.

> In contrast, unauthenticated keying was the primary goal of BTNS (RFC 5387), which thus should be discussed in this doc as well:

Both RFC 4322 and 5387 were barely implemented anywhere. Dredging them up as examples is actively harmful to trying to get a term that everyone can agree on. They were well-intentioned failures, like many efforts in the IETF; let's move on.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2014 11:01:22 -0700

On 3/19/2014 10:37 AM, Paul Hoffman wrote:
> It underscored that OE *as defined in RFC 4322* is not
> unauthenticatedkeying. As many people here have said repeatedly, we
> don't care about what the authors of that document said: the term has
> be reappropriated to mean best-effort keying triggered without the
> user's knowledge.

Best effort keying is not at all the same thing as unauthenticated keying.

Unauthenticated keying is one of many possible alternatives that 
best-effort keying can try and fallback on.

Misuse of terms by others is an opportunity :-) to educate, not to be 
driven by external forces.

>> In contrast, unauthenticated keying was the primary goal of BTNS
>> (RFC5387), which thus should be discussed in this doc as well:
>
> Both RFC 4322 and 5387 were barely implemented anywhere. Dredging
> themup as examples is actively harmful to trying to get a term that everyone
> can agree on. They were well-intentioned failures, like many efforts in
> the IETF; let's move on.

Why do you think those are failures, but everyone else's misuse of the 
terms defined in those documents are not?

Even failures can define terms, e.g., one of the most popular terms for 
a commercial failure is an 'Edsel'.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Mar 2014 15:08:15 -0400

> that yields authenticated, anonymous, or pseudonymous communications

<Blush>

Change:
   The term opportunistic encryption (OE) was coined by Michael
   Richardson in "Opportunistic Encryption using the Internet Key
   Exchange (IKE)" an Informational RFC [RFC4322].  In this RFC the term
   is defined as:

To:
   The term opportunistic encryption (OE) was documented by Michael
   Richardson et al in "Opportunistic Encryption using the Internet Key
   Exchange (IKE)" an Informational RFC [RFC4322].  The term was coined
   by John Gilmore and Hugh Daniel in the mid-1990s. In this RFC the term is defined as:

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Mar 2014 13:03:20 -0700

> Best effort keying is not at all the same thing as unauthenticated keying.

Correct. Stephen has already made that clear in his -00 draft.

> Unauthenticated keying is one of many possible alternatives that best-effort keying can try and fallback on.

Yep.

> Misuse of terms by others is an opportunity :-) to educate, not to be driven by external forces.

The fact that they use the terms differently than you does not mean it is a misuse; this is a community effort.

> Why do you think those are failures, but everyone else's misuse of the terms defined in those documents are not?

They were failures because they were extremely thinly deployed. We can argue what the reasons for that is (I believe there were different reasons for the two technologies), but they are both essentially unused.

> Even failures can define terms, e.g., one of the most popular terms for a commercial failure is an 'Edsel'.

Edsels were more widely deployed than BTNS.

--Paul hoffman

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Mar 2014 20:44:39 +0000

> Anyways, there's a spectrum of security.  The key is to describe that spectrum appropriately -- appropriately for _typical users_ because whatever terminology we settle on will almost certainly find itself into mass consumer consciousness.

There definitely is a spectrum. My personal graduation would be something like:

1) Nothing
2) Prevention of passive attacks.
3) Prevention of passive attacks and non-real-time detection of active attacks.
4) Prevention of both active and passive attacks in real time.

I believe that the "non-real-time detection" is actually valuable. Yes, the communication will be listened to and maybe tampered with. But the act could still be detected later, maybe on a second connect, or a connection from a different location. And that will at a minimum create a PR problem for whoever is doing it...

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2014 13:50:08 -0700

On 3/19/2014 1:03 PM, Paul Hoffman wrote:
...
> Edsels were more widely deployed than BTNS.

Yes, but BTNS foresaw the need for the benefit and utility of 
unauthenticated keying, which is more than can be said for OE.

Co-opting the concept and calling it OE isn't going to change that.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Mar 2014 13:54:19 -0700

> 4) Prevention of both active and passive attacks in real time.

This seems like a short, useful ladder that is easy to understand and probably easy to design to.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Mar 2014 16:09:53 -0500

> This seems like a short, useful ladder that is easy to understand and probably easy to design to.

+1.

Note that things like MinimaLT, CurveCP, even the old -and very
obsolete- NFS AUTH_DH (later mech_dh) protocols can easily provide the
basis for (2), (3), and (4).  You always do an ECDH exchange using a
fixed (for a while) per-origin, per-identity, or per-{origin,
identity} key on the client side, and a key that you can hopefully
validate with DANE for the server.  You get:

 - always at least (2)
 - (4) whenever you can validate the peer's public key with DANE or
similar or have previously established trust on the given peer's
public key or can verify the key out of band
 - (3) if you can do something like
SRP/PAKE/DIGEST/SCRAM/Kerberos/whatever at a higher layer
 - (3*) when you're willing to LoF/TOFU the peer's key (eventually
building trust) (this way you force any MITM to always be in the
middle)

OTR basically covers this range.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Mar 2014 21:19:57 +0000

Whilst I broadly totally agree with this spectrum....

> public key or can verify the key out of band

... WTF? "DANE and similar" are perfect systems that cannot be
actively attacked?

The other two options are vague enough to at least permit perfection.

> OTR basically covers this range.

+1 to the rest.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Mar 2014 21:36:31 +0000

> ... WTF? "DANE and similar" are perfect systems that cannot be

"Prevent" was used loosely upthread.  I prefer to use terms like
"downgrade-resistant", "MITM-resistant", ... which suggest mitigation
rather than immunity.

My long-term plan for Postfix with DANE is to use DANE for
"introduction", and other mechanisms for key-continuity.  When key
continuity (Tack, or similar) fails, go back to DANE, but log the
key continuity failure.  Thus MITM resistance on introduction and
detection thereafter, unless what's compromised is the peer endpoint
or its keys.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Mar 2014 16:39:29 -0500

> ... WTF? "DANE and similar" are perfect systems that cannot be

Oh come now.  No system is perfect.  Some systems (or some trust
anchors, or ...) will meet the user's "policy", whatever that might
be.  There's nothing really new here.  Yes, no one will want a re-run
of the TLS server PKI, with a gzillion trust anchors (and therefore no
trust).

There's a certain amount of conversation state that has to be assumed
if we're to have a complex conversation spanning any realistic amount
of time.  But it is important to establish that state.  The above does
a bit of that.

>> SRP/PAKE/DIGEST/SCRAM/Kerberos/whatever at a higher layer

I neglected to mention that the above one gets you (4) if the
SRP/PAKE/... gets you (4).

>> building trust) (this way you force any MITM to always be in the

How are any of those any more "perfect" than DANE?  There's still a
TTP in the Kerberos case, and there *might* be one in the other cases
(doing something like "passthrough" authentication).

See what I mean?  If you question DANE or any other authentication
mechanism's value, I can question the rest.  If we assume going in
that we agree already that the user will have come to decide what's
appropriate for them (usually they won't have a lot of choices, if any
anyways), then we don't have to pursue this tangent.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Mar 2014 00:29:04 -0400

On 03/19/2014 05:36 PM, Viktor Dukhovni wrote:

> continuity (Tack, or similar) fails, go back to DANE

Because the chance that a registrar/registry is hacked, is greater than the chance of the admin screwing up his TACK ping?

I hope you leave an option in for those who are fine with just DANE :P

Pinning is the new /etc/hosts

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Mar 2014 05:20:43 +0000

On Thu, Mar 20, 2014 at 12:29:04AM -0400, Paul Wouters wrote:

> Because the chance that a registrar/registry is hacked, is greater
> than the chance of the admin screwing up his TACK pin?

Because we'll log the public key fingerprint and let the administrator
decide whether he cares to contact the remote site to check what happened.
Note no interruption of service, just a log entry for those who want to
trust, but verify.

> I hope you leave an option in for those who are fine with just DANE :P

This is not the type of behaviour that I would (or Wietse would
let me) hard-code into Postfix.

> Pinning is the new /etc/hosts

To be fair Tack is intended to be a bit more dynamic than that,
we'll see whether it gains any traction.  We DANE for re-sync,
and just a log entry with DANE verified re-sync, the noise should
be fine.

Anyway this is all rather tentative, Tack has to first be available
in TLS toolkits (OpenSSL in my case), and I'll probably have to
wait quite some time before that's the case.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Mar 2014 13:31:24 -0400

Paul,

> The protracted terminology discussion on SAAG seemed to end with more people wanting to use "opportunistic encryption" with a new definition rather than making up a new term.
I assume that the SEC ADs will inform the list when they determine 
consensus. I didn't see
the discussion "end." I tok a break to publish the I-D, as Stephen 
Farrell requested.
thanks.
> ...at which point it goes off the rails. It tries too hard to make the old term have an important meaning. That discussion also skips over some of the obvious flaws with your new term. For example,…
Gee, that sounds a bit pejorative. I prefer to view the text as a 
reasoned, scholarly discussion
of terminology :-).

The term "opportunistic encryption" has a well defined meaning. The 
deployment status of the
design documented there is irrelevant when deciding whether the term is 
well defined and whether
it is meaningfully distinct from other techniques that have different 
names. One also should note
that Paul Wouters has resurrected the notion from 4322 in a revised 
design (presented to SAAG and IPSECME). The new design avoids what he 
and Michael determined to be major impediments to use
in the old design.

Finally, how can you say that whatever we do to counter PM cannot hope 
to be sufficiently
widely deployed to be called "pervasive?" Stephen Farrell's 
soon-to-be-RFC defines pervasive
in a fashion that tempers the term. Certainly our goal is to have easy 
to use encryption be
as widely deployed as the monitoring it hopes to counter, right?
> No offense, but most of that is just selling well past the agreement. Many of the definitions in Section 2 are not universally agreed on, and trying to force those terms down people's throats is li…
You and I already disagreed on the terms in Section 2 when I asked for 
you feedback a
couple of months ago. I think you even said that nobody cares what RFC 
4949 says. We disagree
on the utility of 4949, and maybe on the desirability of technically 
accurate terminology
in RFCs. I still believe we are not the IMTF and that good terminology 
matters.
> Making the jacket to be five sizes too large just in case we gain a lot of weight is not necessarily good tailoring. Please strongly consider using the term that we had previously agreed on.
"We" previously agreed upon? Not for all values of we :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Mar 2014 13:34:32 -0400

Viktor,
> arrangement (fax effect and all that).
I had prepared a much longer document, which examines key management options
for a variety of security protocols, and it notes the value of using DANE
as a way to provide authenticated key management (as opposed to the Web 
PKI).

I agree that DANE-supplied keys for use with IPsec seems to be an accurate
example of OE, as pre 4322.
>    TLS", or is that name about right. ]
I have not thought about that yet.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Mar 2014 13:50:34 -0400

Nico,
> authentication...  Too close to OAuth.
agreed!
> into mass consumer consciousness.
In part, that's why I like Pervasive Encryption. If we say we're trying
to combat pervasive monitoring, the terminology overlap seems to make it
natural, no matter what we do :-).

On the other hand, one of the precepts Steve Bellovin and other have 
suggested is
that we don't make this visible to users, so that they don't get 
confused and don't
see it as an alternative to authentication sessions. In that case, users 
don't
neer to know exactly what we're doing, or if it's the same for every app.
> likely to come to the attention of mass consumers.
Internal to the IETF we need terminology that is more precise that PE, 
so that
we can distinguish among different solution options, etc. But it can all be
subsumed, for external consumption, under the PE label.
> we need MITM attack resistance/detection in many, many cases (e.g.,
I agree with the example, but, again, if we, as a community, decide that
MiTYM detection is not mandatory and the result is not visible, then ...
> against criminal attackers).
yep.
> (I say "criminal" to distinguish from LEO/TLA agency types.)
yep.
> limit, but possible when you're not interesting)
I don't disagree with the bullets above, but what I think we should consider
when creating criteria for evaluation of new (and existing) protocols is
a prioritized list of attack classes (vs. threats). The list I have in 
mind is:

     1. purely passive attacks (traditional passive wiretapping) against 
payloads
     2. payload wiretapping enabled by an active attack such as DNS 
response injection
        (which may yield a MiTM atack)
     3. wiretapping enabled by exfiltration of traffic keys or a bad PRNG
        (the result of malware on a machine at one end pf the other)

> hard -- the most difficult).
yes, traffic analysis is a bit orthogonal, because it is a function, in 
part, of
the layer at which the payload is encrypted. So one can rate the severity of
TA based in part on the layer at which encryption is offered, then based on
the extent to which the encrypted traffic still exposes info about 
communication.

> for long (i.e., force an MITM to be there the first time and always)
I'm concerned that the first bullet is a security goal, while the second
is an example of a security mechanism
> (authentication + encryption)
again, a pair of security services
> and I believe we need terminology that mass consumers can understand.
we need to decide if a user will even know when PE is employed.
if not, then it may not be important to communicate the distinctions
to the masses.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Mar 2014 18:41:08 +0000

Steve,

I like lots of the text in the draft, thanks.

However, I don't think the PE term is going to be that
useful for us and have a possible concern about direction.
I also have a suggestion, just to see how it lands...

On PE: I think the term as defined is cute and defensible,
but I think it'll cause us problems if we try adopt it
broadly, since it'll generate too much opposition from the
"but I don't want to encrypt" camp. If however, a strong
consensus emerged for the PE term, I could live with that
but I don't see it yet, and personally I preferred your
previous OK suggestion, or re-defining OE. The word
opportunistic really does seem to me to be the best match
for what I see most people talking about to be honest.

About direction: I think that perhaps the draft overspecifies
PE/OK/OE in ways, e.g. your point #2 saying PE is not a
substitute. We know that in many cases mutually authenticated
crypto can be used, but that it is often not used because its
perceived as too heavy-weight. Now you do say that the list
are characteristics that PE exhibits, so this might just
be a case of worthsmithing being needed, but I don't think
it'll be useful if we end up with terminology that just
causes more arguments, e.g. "that protocol cannot do PE/OK/OE
because it would be possible to do mutual" is not where
we want to end up.

And a suggestion: given that the word opportunistic is
what is being used, how's about we describe ways in which
the word opportunistic can sensibly be used when discussing
keying and encryption. For example by saying that it means
doing key exchange and encryption at the opportune time in
an opportune manner?

In terms of your text that'd mean something like:

OLD:

   PE (for realtime communication) exhibits the following
   characteristics:

NEW:

   The term opportunistic when used to describe security
   mechanisms used in a protocol basically means doing
   key exchange and encryption at an opportune time in
   an opportune manner, without tightly coupling that
   with endpoint authentication.
   Protocols doing key exchange and encryption can
   usefully be described as opportunistic if they exhibit
   characteristics such as the following, when those are
   relevant for the protocol concerned:

And then your list, which (modulo wordsmithing), I like.

Lastly, I recognise that probably you and I disagree about
it, but I do not think that we need to honour the definition
of OE as previously used in RFCs. We do need to note it,
and say why we're changing it if we do and how any new
definition differs from previous usage. Things move on and
if we have consensus to re-define that term, that's just
fine. I'd be interested in more opinions on that issue.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Mar 2014 14:48:39 -0400

> "but I don't want to encrypt" camp. If however, a strong

Can you tell me more about this camp?
I am not familiar with who they are, and what they say.
(And I wasn't at STRINT)

    > doing key exchange and encryption at the opportune time in

Maybe we could translate the word opportunistic into another language,
and use that term.  Probably a non-latin based language, but which
has good latin-1 transliteration.

Seriously.

We seem to all know what we mean here, we are just bikeshedding on a word.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Mar 2014 19:26:53 +0000

On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote:

> Probably a non-latin based language, but which

This is likely not a fruitful direction.  None of French, German,
Russian, ... yield anything better, mostly variants of the same
latin word.

I had to switch to Hebrew to find a reasonably short word that was
different, but I doubt that "staglani" (with stress on the "nee")
is going to serve us better.

    http://translate.google.com/#iw/en/%D7%A1%D6%B0%D7%AA%D6%B7%D7%92%D7%9C%D6%B8%D7%A0%D6%B4%D7%99

Nor are we likely to gain much clarity from the Maori "kapo".

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 20 Mar 2014 16:10:28 -0400

> We seem to all know what we mean here, we are just bikeshedding on a word.

Indeed, and so far all the existing candidates have contextual meaning
or nuance that causes various people to complain.

To be clear, i think we're all talking about a best-effort,
"on-by-default" encrypted replacement for cleartext as a way to raise
the cost of pervasive monitoring.  We're just lacking consensus on what
we should call that basic concept.

here's my abbreviated take on the major complaints for existing
candidate terms:
---------------------

"Opportunistic encryption" isn't ideal because it has other historic
meanings.

"Unauthenticated encryption" is inaccurate because some of these
connections might actually be authenticated (and because it appears to
contrast with "authenticated encryption" which is a specific term of art
in the crypto world, related to message integrity)

"Pervasive encryption" is likely to be inaccurate because (sadly) we
won't win and get everything to be encrypted (it won't be truly
pervasive) any time soon.

"Opportunistic keying" seems a bit off because we're not just discussing
choosing keys, but also talking about the way those keys are used.

---------------------

i'll throw one more candidate term into the ring that i think avoids the
problems listed above:

 "Hygienic encryption"

I'm proposing this from a public health analogy (e.g. [0]): a
best-effort, on-by-default, encrypted replacement for cleartext as a
defense against pervasive monitoring is like washing your hands after
using the toilet.  Everyone should do it for the social good, and it's
also not enough to protect you from disaster or deliberate, targeted
compromise.

I am not going to passionately advocate for this term. i'm aware of
https://xkcd.com/927/   I'm just offering a term that everyone might be
willing to settle on (even if it's not your favorite) so we can stop the
bikeshedding, get this stuff in place, and (most importantly) maintain
our focus on even stronger measures that are still needed.

	--dkg

[0] see "Security as an exercise in public health", from
http://www.theguardian.com/technology/2014/mar/11/gchq-national-security-technology

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 16:07:43 -0500

On Thu, Mar 20, 2014 at 01:50:34PM -0400, Stephen Kent wrote:
> [...]

Cute.

> [...]

Substitute "sometimes works against active attackers" for the mechanism.

The mechanism is not the salient fact.  Although it can be if it means
leaking into UIs (e.g., as in traditional SSH LoF).

> [...]

> [...]
> suggested is that we don't make this visible to users, so that they
> don't get confused and don't see it as an alternative to
> authentication sessions. [...]

If users won't be aware of it at all then it should just be
unauthenticated key agreement + authenticated symmetric encryption.

I'd call that "pervasive", yes, but the term will leak into mainstream
use.  I think we should plan on users knowing about it even if it were
easier if they didn't.

DANE and/or TACK could be used but now failures to match expected keys
will mean making users aware (and they'll need a way to override, won't
they, the usual give-my-money-to-the-bad-guys-OK button on a dialog).

> so that we can distinguish among different solution options, etc. But

Agreed.

> it can all be subsumed, for external consumption, under the PE label.

I thought you didn't want users to be aware of it.  Why would we need a
"PE" label for them to see?

:)

(My point is we'll have to try to pin the marketing aspect of this down
a bit.)

> >[...]
> a prioritized list of attack classes (vs. threats). The list I have
> in mind is:
> 
>     1. purely passive attacks (traditional passive wiretapping)
> against payloads

We can't help local security from a protocol point of view.  On the
contrary, we can only have network security if we have local security to
start with (I know this is a rather defeatist seeming position! but it's
correct).  Therefore we should not consider (3).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 16:20:35 -0500

>> natural, no matter what we do :-).

Hmm, cute but dangerous.  The pervasive monitoring is mostly TLAs/LEOs
or their deputized agents, and they have the resources and position to
mount active attacks.  Therefore PE had better to much better than
just protect against passive attacks or we may end up with a major
marketing failure in our hands, and badly damaged reputation.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 16:24:53 -0500

> or nuance that causes various people to complain.

If the whole world will see this bikeshed and measure us by its color,
then our color choice will matter.  If not, not.  I'm not sure yet
what the intention is (see Stephen's response to me).

> here's my abbreviated take on the major complaints for existing

"Lying" in a direction of making the user feel less safe than they are
is at least somewhat better than the alternative...

> i'll throw one more candidate term into the ring that i think avoids the

In so far as it says nothing to me, I like it!

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Mar 2014 22:04:08 +0000

> In so far as it says nothing to me, I like it!

In so far as it says nothing to me, I don't see using it.

Many messages up-thread multiple people suggested that "OE" works
well enough, and ought to be re-purposed (definition broadened).

We've been using the adjective "opportunistic" in combination with
a few related nouns for some time, and at various administrators
and users have a working knowledge of what it means.  Nothing I've
seen so far fits as well.

Even the negative connotations of "opportunistic" are a feature,
in the sense that they carry an connotation of going for "all you
can get", no ceiling!  Which is precisely the goal here: as secure
as practically possible.  Without raising the bar so high that one
is left with no security because one could not attain some notion
of absolute security.

It would be nice if "opportunistic" security became "pervasive",
but naming it so I think focuses on an extrinsic property, the
desired scope of its popularity, rather than an intrinsic property
like aiming for the most you can get without a set lower or upper
bound.

Someone might now suggest "unbounded encryption", but that would
suggest superior capabilities, rather than achieving the most one
can.  So bottom line, I am with the folks who say we were already
done choosing the term, and it is time to explain it to the world
and promote the approach in all relevant protocols and products.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 18:10:04 -0500

> We seem to all know what we mean here, we are just bikeshedding on a

This is not bikeshedding.  Names matter.  Consider BTNS...

BTNS failed for many reasons, but one of them was that the name
indicated much less utility than it provided.

BTNS (_with_ connection latching) is basically what's being proposed
today, only not using IKE (nor ESP).  It would have made possible the
use of DANE, TACK-like mechanisms, and channel binding -- all the things
we want for "PE", "HE", "OE", or whatever we end up calling it.  So what
was wrong with it?  I won't make a full list, just two reasons sufficed
methinks:

1) In-band key exchange (and any authentication) is better (i.e., more
   deployable, easier to manage, ...) than out-of-band (read: IKE);

2) visceral reaction to the name.  Many people took BTNS as a
   pejorative and spoke despectively about it.

What's in the name matters at least a fair bit, probably a lot.

A discussion about naming is warranted even where a discussion of
bikeshed paint color wouldn't be.

I'm now convinced that "pervasive" as a modifier for "encryption" or
similar will denote (to enough people) something very different from
what is to be provided, therefore it would be extremely dangerous to
settle on "pervasive".

We need a name that denotes what we mean to provide.

I simply cannot find a better adjective than "opportunistic" for use in
"<adjective> encryption" adjectival phrases.

I counsel the use of an adjective at least as appropriate as
"opportunistic" and no less.  Consider a thesaurus:

http://thesaurus.com/browse/opportunistic

None of the "synonyms" of opportunistic listed there comes close to
being appropriate here.  Except, maybe, for "pretentious" (under "as in
vaulting") or "blasé" (under "as in worldly"), and those bear a much
more negative connotation.

To be fair, some dictionaries' definitions of opportunistic carry very
negative connotations, but I think when attached to a noun that carries
possitive connotations the sense of opportunistic is reversed (which in
turn is likely the reason that thesauruses are not helping).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 18:17:46 -0500

> In so far as it says nothing to me, I don't see using it.

I was being somewhat facetious: if I can't have the adjective of my
preference for this ("opportunistic") then I'd rather have an empty
vessel into which to pour our meaning.

But you've convinced me: it's opportunistic or nothing.

Past uses of "opportunistic encryption" with different meanings are not
relevant: they're not in widespread use, certainly not in the
conciousness of the public, and certainly not likely to ever be as
widespread as we want this new thing to be.

Agreed.

> Even the negative connotations of "opportunistic" are a feature,

Yes: because when attached to a noun that has positive connotations the
sense of "opportunistic" is reversed from negative to positive!

"Opportunistic" is an opportunistic adjective.  (ahem, pardon me.)

Nico
--

---

From: Ira McDonald <[email-masked]>
Date: Thu, 20 Mar 2014 21:35:55 -0400

Hi,

To be useful, the chosen term should be obvious and meaningful to end
users,
not just to administrators.

In popular usage, the adjective "opportunistic" falls into the same deep
hole of
probable misunderstanding that Nico noted for BTNS.

I suggest that only positive adjectives be considered, for example:

  "practical encryption"

Now please shoot the messenger (smile).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Mar 2014 21:57:23 -0500

On Thu, Mar 20, 2014 at 09:35:55PM -0400, Ira McDonald wrote:
> users, not just to administrators.
> 
> In popular usage, the adjective "opportunistic" falls into the same
> deep hole of probable misunderstanding that Nico noted for BTNS.

I don't think so, for the reasons I gave in other posts.  But I
recognize my own bias may blind me to the truth of your statement.
That's why I suggested a survey.

If we're really going to try to greatly improve the lot of Internet
security, we'd better get various details right, right down to the name
that the public will hear.

We could also reach out to English and/or marketing experts.

> I suggest that only positive adjectives be considered, for example:

"Opportunistic" is only negative when considered alone or with nouns
with negative connotation.  Otherwise it ranges from neutral to positive
connotations.  The thesauruses I looked at don't capture this.

Consider all of these nouns as modified by opportunistic:

   opportunistic politician
   opportunistic investment
   opportunistic infection
   opportunistic sale
   opportunistic theft
   opportunistic leisure
   ...

Search for these phrases in quotes, you'll see what I mean.

>   "practical encryption"

"Opportunistic encryption" says (to me) "we encrypt when we can", which,
is about right (even if we always encrypt, the important part is that
which we won't always be able to do, namely: authentication, and which
the uninitiated will tend to understand intuitively by "encryption").

To my ear, "practical encryption" ranges from "not impractical" (hah) to
"it does what you would expect" (except it won't always, so we're back
onto thin ice).

Also, remember that the problem with OE was reuse of the term.  How
about "opportunistic security"?

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 11:53:06 +0000

On 03/20/2014 11:10 PM, Nico Williams wrote:
> This is not bikeshedding.  Names matter.  

I agree with Nico's conclusion in this case, though I might get
to it via a different route.

It seems fairly clear that we are not so far getting consensus
for any term that does not include the word "opportunistic."

Do folks agree with that?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 11:59:53 +0000

On 03/20/2014 06:48 PM, Michael Richardson wrote:
>> broadly, since it'll generate too much opposition from the "but I
>> don't want to encrypt" camp. If however, a strong
> 
> Can you tell me more about this camp? I am not familiar with who
> they are, and what they say. (And I wasn't at STRINT)

That wasn't really to do with STRINT, more from the gigantic
IETF LC for perpass-attack. There were a very few folks who
just don't want to encrypt stuff. One or two who want to send
stuff via Ham radio and are not supposed to send ciphertext.
And one or two more I just never could figure the reason why.

But mostly, its really folks who don't want other folks
to encrypt for a mixture of good and bad reasons. We do
not need to delve into it here, but IMO a defensible reason
to not want everything to be ciphertext does exist which
is inbound malware scanning. (I'm not saying that that
wins the argument, just that its a defensible argument.)

People who want/need to do that would be dead against a
thing called pervasive encryption I'd bet.

S.

---

From: Mouse <[email-masked]>
Date: Fri, 21 Mar 2014 09:56:37 -0400 (EDT)

>>> [...], since it'll generate too much opposition from the "but I
>>> don't want to encrypt" camp.
> There were a very few folks who just don't want to encrypt stuff.
> One or two who want to send stuff via Ham radio and are not supposed
> to send ciphertext.

I had this reaction when I saw, upthread,

> We are going around in circles. I think we - the larger Internet
> Community - ned to explain this and get everyone that manages a
> system, that configures software to get aboard this ship.

My reaction, as a sysadmin and software configurer, is that you will
never get me aboard any ship that involves encrypting everything.  I
didn't mention it because I saw no point; I'm enough of an outlier, and
see so much that's so much worse wrong with the Internet already, that
it didn't strike me as worth the electrons it would cost.  But, yes, I
do not want to encrypt stuff - or, at least, there plenty of stuff I do
not want to encrypt.  There are two basic reasons for this: (1) I like
to be able to see what's going on on my network by snooping on
intermediate nodes, and (2) the computron load imposed by encryption is
significant for enough of my machines to matter to me.  Additionally, I
see

(3) a nontrivial fraction of my traffic is already encrypted, making
further encryption an almost total waste of resources; this matters
most for the machines for which (2) is relevant, so it's really a
subset of it.

(4) This puts a good deal of relatively complex, and very difficult to
vet for even people usually pretty good at code vetting, code in
security-critical paths.  This wouldn't matter much - if the encryption
is bad, the security properties are no worse than what you get from
sending in the clear - except that people will feel safe even if they
aren't.  (A lot of people seem to think of "safe" (or "secure") as a
boolean thing, not the spectrum it actually is, exacerbating this.)

Come to think of it, there's also (5) some people are in places where
encryption is illegal or under onerous legal restrictions.  Would you
exclude them from the net entirely?  (This is basically the argument
about the hams in a different dress.)

Oh, and (6) a good deal of my traffic is stuff that's public anyway
(like FTPing from my anonymous FTP area, or public mailing list mail)
and encrypting it is thus a total waste of resources.

(1) can be seen as a case of "folks who don't want other folks to
encrypt" where I am both the "folks" and the "other folks" (and thus
the description's "other" is inaccurate).

Of course, how much of an argument this forms for the IETF is for the
IETF to determine.  Internet governance is already headed in directions
antithetical enough to me that I have learned to not expect anyone to
care what I think.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Mar 2014 07:34:37 -0700

> Do folks agree with that?

Yes.

Separately, I would argue that if we use "opportunistic foo" which is not "opportunistic encryption", that definition will have to differentiate the two and the difference will be obscure even to developers. At that point, we look silly for not just redefining the term everyone is already using, "opportunistic encryption".

--Paul Hoffman

---

From: Dan Brown <[email-masked]>
Date: Fri, 21 Mar 2014 14:41:35 +0000

Hi Stephen,

My bikeshed vote would go to

passive encryption

3 reasons: resists passive attacks, user can be passive, massive
surveillance hindered

To me, pervasive mainly conveys the upside, but not downside risk of a MITM.
Opportunistic seems too much like occasional, whereas the goal is to be
frequent, and again does not convey the downside risk (MITM).  Also, both
words also have a rather mischievous connotation, which might be unfair to
users not even aware of its use.

Best regards,

Dan

PS BTW, more brainstormed alternative terms:

casual encryption
provisional encryption
presumptive encryption
eager encryption
expedient encryption
procedural encryption
quotidian encryption
nominal encryption
pencil encryption
pragmatic encryption
bicycle encryption

WordNet helped me to find some of the brainstorm adjectives above. I often
started from a term for either the upside or downside, then searched for a
related term that had both an upside and downside.

Right now, I see any of the above to be as good as pervasive or
opportunistic, but not as good as passive.

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, March 21, 2014 7:53 AM
> To: Nico Williams; Michael Richardson
> Cc: saag
> Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology)
> 
> 
> 
> I agree with Nico's conclusion in this case, though I might get to it via
a different
> route.
> 
> It seems fairly clear that we are not so far getting consensus for any
term that
> does not include the word "opportunistic."
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 21 Mar 2014 15:43:45 +0100

> Separately, I would argue that if we use "opportunistic foo" which is not "opportunistic encryption", that definition will have to differentiate the two and the difference will be obscure even to d…

Yes, we would. 

We have a group here in Sweden trying to come up with swedish names for computer-related terms. We decided that floppy disc was "flexskiva". I don't think anyone will remember that term, even though it was technichally correct and a proper translation of "floppy disc". It became "Floppy" and stayed "floppy". I just asked my son if he knew what a "flexskiva" is and he looked at me with an empty stare. "Floppy" he knew immediately :-)

Long story, but I do agree with Paul. Let's take ownership of the term "opportunistic encryption". We don't have the resources to get a new term out there, established in time for what we want to do. 

Let's try to define a common definition of the goal with "opportunistic encryption" in non-detailed way. Then let's define all the solutions that is grouped under this in a detailed, correct and well-defined way.

(ducks)
/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Mar 2014 14:56:40 +0000

> > Do folks agree with that?

And yes.  I have in the back packet other adjectives that are close:
"adaptive", "pragmatic", "flexible", "scalable", but none fit as
well.

> Separately, I would argue that if we use "opportunistic foo"
> which is not "opportunistic encryption", that definition will have
> to differentiate the two and the difference will be obscure even
> to developers. At that point, we look silly for not just redefining
> the term everyone is already using, "opportunistic encryption".

I take strong exception to this.  Coining the term "green bike-shed"
does not confuse people about what "green" is.  There is 8 years
of history behind "opportunistic TLS" in Postfix and I see no reason
to change that, just because an umbrella term to cover more than
TLS has been proposed.  The term "opportunistic TLS" is simply
a more specific version of "opportunistic encryption", and
"opportunistic DANE TLS" is a more specific form still.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Mar 2014 08:21:01 -0700

> "opportunistic DANE TLS" is a more specific form still.

Saying that the Postfix's community use of a specific definition of "opportunistic TLS" should trump the large value of having a single definition for "opportunistic encryption" feels somewhat selfish. Note that Michael Richardson, whose RFC was the first to use the term "opportunistic encryption", have given up change control on the term so that we can get more universal encryption.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 15:33:06 +0000

Folks,

>>>> Do folks agree with that?

I deliberately stopped with the above question. So far
I've seen a number of yes responses, one set of alternate
suggestions (without an answer to the above question)
and have also gotten a few offlist mails with yet more
alternative suggestions.

If we can bottom out on *just* the above question, then
we can go on to see how best to proceed, but e.g. the
discussion between Paul and Viktor would be part of that
next step, *after* we end up concluding that we have
rough consensus on the answer to the above question.

I think if we take this one step at a time, we're more
likely to make progress.

Thanks,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Mar 2014 15:33:28 +0000

On Fri, Mar 21, 2014 at 08:21:01AM -0700, Paul Hoffman wrote:

> Saying that the Postfix's community use of a specific definition
> of "opportunistic TLS" should trump the large value of having a
> single definition for "opportunistic encryption" feels somewhat
> selfish.

I have nothing against "opportunistic encryption" as an umbrella
term for lots of more specific terms.  There is nothing wrong with
one of the more specific terms being "opportunistic TLS" or
(synonymous) "opportunistic TLS encryption".  This is really just
a special case that is aligned with the umbrella term.

We don't at this time need to decide to ban related, non-conflicting
uses of the adjective, that can be done on a case-by-case basis
where there is specific likelihood of confusion.

Adjectives can and do decorate multiple nouns without confusion.
This sub-thread is a side-show, I think we should return to the
main topic if there is anything further to say on that.  Otherwise,
we have our winner.  (What was it again?  Did I hear someone say:

	Scalable Opportunistic Adaptive Pragmatic Encryption?

with the acronym SOAP-E?  Now that's marketing! :-)

-- 
	Viktor.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 21 Mar 2014 15:35:21 +0000

> Do folks agree with that?

[Joe] yes.

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 11:18:11 -0500

> with the acronym SOAP-E?  Now that's marketing! :-)

Fortunately the public isn't conscious of the horrors of SOAP, so that
would actually work!

:^)

The public does like acronyms, you know.  So that might actually work.
 And a bag-full of adjectives might be the right approach to convey
what we must through redundancy -- no SPOF in our naming :)

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Mar 2014 14:03:09 -0400

Olle E. Johansson <[email-masked]> wrote:
    > Long story, but I do agree with Paul. Let's take ownership of the term
    > "opportunistic encryption". We don't have the resources to get a new
    > term out there, established in time for what we want to do.

okay.

    > Let's try to define a common definition of the goal with "opportunistic
    > encryption" in non-detailed way.

Is "non-detailed" a technical way to say, "marketing"?
If so, I'm with you.

    > Then let's define all the solutions
    > that is grouped under this in a detailed, correct and well-defined
    > way.

And the detailed, protocol-specific mechanisms can have super-cool and/or
ultra-obscure, but 100% collision resistant acronyms?  I'm for that.

====

X: "Hi, I'm Mr. X, VP marketing of Example Inc.
    Our new product has Opportunistic Encryption"

Me: "Oh, that's awesome. Does it support the OE FLEXSKIVA method?"
X: (shuffles papers), "Oh, yes, we support FLEKXIVA, no problem!"

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Mar 2014 14:04:32 -0400

Paul Hoffman <[email-masked]> wrote:
    > Saying that the Postfix's community use of a specific definition of
    > "opportunistic TLS" should trump the large value of having a single
    > definition for "opportunistic encryption" feels somewhat selfish. Note
    > that Michael Richardson, whose RFC was the first to use the term
    > "opportunistic encryption", have given up change control on the term so
    > that we can get more universal encryption.

And if I could withdraw 4322, to make this process more Happy Happy Joy Joy,
I would. :-)

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 11:19:30 -0700

> And if I could withdraw 4322, to make this process more Happy Happy Joy Joy,

And that's part of the confusion; using a term that originates in that 
RFC in a way that is explicitly noted as excluded *in that RFC* will 
continue to cause confusion as long as the term is used to mean both things.

That's good reason for using a new term. Familiarity isn't necessarily 
be worth the baggage.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 11:27:00 -0700

On 3/20/2014 4:10 PM, Nico Williams wrote:
> today, only not using IKE (nor ESP).

IMO, it is the persistent desire to bolt BTNS to other components (like 
connection latching) that undermines its utility and pervasiveness.

BTNS was intended to obviate the need for PKI altogether and show the 
benefit to doing authentication even without confirming identity, 
whereas connection latching just moves that need to a different protocol 
layer.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 11:43:18 -0700

> we should call that basic concept.

This hits one of two key aspects:

	1) always there (on by default)

	2) not what you really want, but
	"better than nothing"

	(that's where BTNS comes from)

So maybe something hitting more on point #1 than #2:

	- reliable security

	- minimally reliable security

Or, if you want "marketing"

	- minimal and reliable security (MARS)

??

Joe

---

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

> And if I could withdraw 4322, to make this process more Happy Happy Joy Joy,

Just update it, give it a new name, or simply note that it has nothing
to do with the new meaning of the term.  There's no need to make this
too hard :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 14:15:05 -0500

> connection latching) that undermines its utility and pervasiveness.

I'm not sure how to put this diplomatically, but I'll try.  End-to-end
IPsec w/o connection latching is *worse* than the TLS renego and
resumption bugs, and for the same sorts of reason: missing
cryptographic bindings.  The only reason that nobody gives a damn
about that problem is that nobody uses IPsec for anything other than
VPN or in small networks.

If we don't learn the lessons of the TLS debacles (each and every one
of them) then let's just give up.

> benefit to doing authentication even without confirming identity, whereas
> connection latching just moves that need to a different protocol layer.

You're confusing your intentions for BTNS with mine.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 14:16:47 -0500

>         - minimal and reliable security (MARS)

No, no, and no.  No names that invite condescension.  We've seen that
movie.  Let's try something original instead of a rerun.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 12:18:37 -0700

> On Mar 21, 2014, at 12:15 PM, Nico Williams <[email-masked]> wrote:
> 

Given I took BTNS to the IETF, I'm not confused at all. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 12:19:58 -0700

> On Mar 21, 2014, at 12:16 PM, Nico Williams <[email-masked]> wrote:
> 

That would be fine too. O* being a rerun. 

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 14:33:33 -0500

> Given I took BTNS to the IETF, I'm not confused at all.

You know -or should remember- that that's not quite right.  You're
leaving out a lot of details.  It's a forgivable error.  I don't want
to get into a pissing match because it's not becoming, and I don't
want to embarrass myself as much as you have yourself.  I'll leave it
here.  I ask you instead to stop acting as though your intended use of
BTNS was the only one.  If you want to continue this I recommend we go
off-list so we stop lowering the signal-to-noise ratio on the list.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 13:01:43 -0700

On 3/21/2014 12:15 PM, Nico Williams wrote:
> IPsec w/o connection latching is*worse*  than the TLS renego and
> cryptographic bindings.

FWIW, there's nothing worse than a connection that cannot make progress, 
and that's what happens when you have TLS that can be shutdown.

BTNS IPsec stand-alone (without connection latching) accomplishes a few 
things:

	- raises the bar of attackers, who now need  to participate
	in the DH exchange as a MITM to succeed (vs just sending
	individual packets that don't require computation)

	- keeps a connection from being shutdown in-progress by
	off-path attacks; once you've connected, you stay connected

Those are worth something. Not what TLS provides, and not what IPsec 
provides, but "better than nothing".

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 15:12:17 -0500

On Fri, Mar 21, 2014 at 3:01 PM, Joe Touch <[email-masked]> wrote:
> FWIW, there's nothing worse than a connection that cannot make progress, and
> that's what happens when you have TLS that can be shutdown.

We don't care: BGP is stupid.  We're talking about !BGP.  We may even
be talking about !TCP.  We're NOT going to have success with an
IPsec-based solution (the specs necessary for that are already
published).

The trend is to deal with all problems at the app layer.  People have
written high-performance TCP/IP user-land stacks and others have
written kernel-mode apps, all using TCP or UDP and no IPsec in sight.

If apps need to reconnect, they will.  That's why we have so much work
going into things like TCP Fast Open or TLS zero-round trip session
resumption.  That's the future: in-bad key exchange.  It's the future
because out-of-band key exchange (i.e., IKE) failed, and it failed for
many, many reasons all of which can be summarized as: a) out-of-band
== lots of OS infrastructure which b) was never good enough that the
apps got enough control or information.

You're stuck in the past Joe.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 13:26:08 -0700

> IPsec-based solution (the specs necessary for that are already

Agreed; the idea of using DH without signatures can be applied to any 
layer - e.g., TLS (on both ends, not just one), TCP-AO, etc.

> The trend is to deal with all problems at the app layer.

The trend is to reinvent the Internet at the app layer; not all trends 
are good. But even at the app layer, or in app-layer tunneled 
implementations (e.g., IPsec over UDP), there is a benefit to providing 
some security without assuming any PKI.

> If apps need to reconnect, they will.

They will try, but it comes at a cost. Regardless, there's benefit to 
having security that makes fewer assumptions but still provides 
something better than the absence of security.

...
> That's the future: in-band key exchange.

In-band or out-of-band, assuming PKI is the problem, and the past we 
need to move beyond.

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 15:36:09 -0500

On Fri, Mar 21, 2014 at 3:26 PM, Joe Touch <[email-masked]> wrote:
> The trend is to reinvent the Internet at the app layer; not all trends are
> good. But even at the app layer, or in app-layer tunneled implementations
> (e.g., IPsec over UDP), there is a benefit to providing some security
> without assuming any PKI.

This trend is a very, very good one.  Are you familiar with mosh
(http://mosh.mit.edu/)?  You should be.

Mosh solves mobility... because TCP doesn't.  Because all relevant IP
mobility options are too complex, not in widespread use or available,
or have annoying trade-offs.

Is that bad?  No!  If the IETF missed the boat on mobility at the TCP
and/or IP layers, well boo-hoo and too bad.

But it also indicates that often we should do less at the lower layers
and more at the higher layers.

Yes, we can be more efficient at lower layers.  That's why I wanted
BTNS w/ connection latching and CB: so we could push crypto down to
the ESP layer, where a) we'd have fewer cryptographic
keys/schedules/contexts (NFS multiplexes multiple users' traffic on
one connection, so that's a win), b) it'd be easier to fob off the ESP
crypto onto NICs like Sun's Neptune NIC.

It didn't happen.  Get over it.  Instead we now have AES-NI and such,
so we can cope.

> They will try, but it comes at a cost. Regardless, there's benefit to having
> security that makes fewer assumptions but still provides something better
> than the absence of security.

With TCP FO and zero-round trip resumption the cost is minimal.  With
UDP there's equivalent costs.

> In-band or out-of-band, assuming PKI is the problem, and the past we need to
> move beyond.

PKI is orthogonal.  I'm making zero assumptions about authentication
technology.  Stop confusing things.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 13:45:22 -0700

> and more at the higher layers.

That's an argument for overlays, but not necessarily for reinventing the 
Internet at the app layer.

...
> technology.  Stop confusing things.

Sorry, but if you don't get around the PKI problem, your approach is 
already DOA.

PKI *is* the problem.

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 15:52:09 -0500

On Fri, Mar 21, 2014 at 3:45 PM, Joe Touch <[email-masked]> wrote:
> Sorry, but if you don't get around the PKI problem, your approach is already
> DOA.
>
> PKI *is* the problem.

The whole point of whatever we're going to call that which is being
proposed in this and related threads is to start by providing
ephemeral-ephemeral [EC]DH key exchange, unauthenticated.  I.e., NO
bloody PKI.  *Then* attempt too to do something for authentication,
such as DANE, PKI, Kerberos, anything, anything you can make work
that's appropriate to the apps'/user's context/policies/goals.

I guess you just haven't read these threads, so you're just making
noise.  Please stop.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 14:04:13 -0700

On 3/21/2014 1:52 PM, Nico Williams wrote:
...
>> PKI *is* the problem.
>
> The whole point of whatever we're going to call

It may be YOUR point, but it isn't mine...

> that which is being
> bloody PKI.

No PKI for the first step...

> *Then* attempt too to do something for authentication,

These all end up assuming preshared keys or PKI. So you're back where 
you started in terms of getting things to work "all the time".

FWIW, the result is exactly what we called BTNS-CBB in RFC 5387, except 
applying them to other protocols that aren't IPsec (which nothing in 
BTNS was really tied to, except by instantiation of specific protocol 
changes).

Joe

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 16:13:43 -0500

> No PKI for the first step...

Right.

> These all end up assuming preshared keys or PKI. So you're back where you
> started in terms of getting things to work "all the time".

I'm done responding to you.  You're just making too much noise.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Fri, 21 Mar 2014 17:15:41 -0400

> ephemeral-ephemeral [EC]DH key exchange, unauthenticated.  I.e., NO

That was not my impression. That might be one mode of things, but authentication via DANE out-of-band still falls within my candidate definition of "opportunistic"

(based on: I am told to initiate unencrypted, let's look in DNS if i can do better than that)

Paul

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 16:19:44 -0500

> That was not my impression. That might be one mode of things, but authentication via DANE out-of-band still falls within my candidate definition of "opportunistic"

Right.  Where do we disagree?

Right.

Remember the context: Joe claims doing anything more than
unauthenticated DH == PKI, omg omg!!!  So you're picking nits in my
response to Joe's silliness, which isn't useful if you agree he's
being silly :)

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 14:25:32 -0700

On 3/21/2014 2:19 PM, Nico Williams wrote:
> unauthenticated DH == PKI, omg omg!!!

I'm not saying that doing more is silly, but it absolutely requires more 
infrastructure:

	- channel binding across layers

	- some sort of signed authentication at the higher layer
		- which necessarily assumes some sort of keys,
		either preshared or distributed

Doing anything more than unauthenticated keying might be opportunistic, 
but it's not "always on" because there will be cases where the keying 
material is not available.

IMO, that's less useful, and one of the failures of the BTNS WG in 
focusing solely on BTNS-CBB to the exclusion of considering the benefits 
of BTNS-SAB (stand-alone, without keys or bindings at other layers).

If that's silly, fine. If that's out of scope for this thread, even better.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Mar 2014 21:39:43 +0000

On Fri, Mar 21, 2014 at 05:15:41PM -0400, Paul Wouters wrote:

> > NO bloody PKI. 
> 
> That was not my impression. That might be one mode of things,
> but authentication via DANE out-of-band still falls within my
> candidate definition of "opportunistic"

Yes, as stated up-thread.

Folks, I think we've derailed again.  There is no real disagreement
about the beast we're trying to name, or perhaps more to the point,
this is not the thread that defines the beast precisely.

Rather this is the thread for agreeing on a reasonable name which
can then be defined to cover various use-cases, and elaborated in
various application protocols, ...

Sorry about the knee-jerk reaction to Paul's comment about
"opportunistic foo", whether he is right or wrong, that is
not the subject of this thread.

RETURN TO MAIN THREAD:

Though I've said it before, my vote is for "opportunistic foo".
With the "umbrella" foo being "encryption", and where appropriate
other foo's that are consistent with the umbrella term.

If we have not already finished the consensus building, please
indicate any strong preferences for or against just the umbrella
term.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Mar 2014 16:44:50 -0500

> RETURN TO MAIN THREAD:

+1 for this.  Thanks.

+1.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 15:06:51 -0700

> indicate any strong preferences for or against just the umbrella

If you're linked to keys elsewhere (e.g., DANE, etc.) +1

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 22:47:01 +0000

On 03/21/2014 09:39 PM, Viktor Dukhovni wrote:
> 
> Folks, I think we've derailed again. 

Thanks Viktor. The bikeshed was busy while I was at dinner;-)

So far we've seen nobody who claims to think we can achieve
consensus for another term. Some have suggested other terms
but nobody has claimed that any of those seem to be getting
consensus.

So, if someone thinks that some other term could achieve rough
consensus please do make that argument now. Note: I don't mean
suggest more terms, I mean make an argument for why one/some
other term can in practice get rough consensus. Note also that
I mean "can" there, and not "should, in my perfect world."

Thanks,
S.

PS: If things remain the same, then the next question will
be how to handle the word opportunistic, but let's please
hold off on that until we get the first thing out of the
way. Monday will do for that if things stay the same.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:58:21 -0400

Michael,
> Stephen Kent<[email-masked]>  wrote:
I didn't see a mention of this earlier use of the term in your RFC. Is there
any written record of the earlier use by these folks?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:58:26 -0400

Nico,

> leaking into UIs (e.g., as in traditional SSH LoF).
I'm not complaining about the mechanism, just the mixing of security service
descriptions and mechanisms. And yes, LoF/TOFU usually involves a user 
accepting
a new credential, an that runes counter to the "invisible to the user" model
some folks have suggested. Good point.
> unauthenticated key agreement + authenticated symmetric encryption.
OK.
> use.  I think we should plan on users knowing about it even if it were
fair point.
> they, the usual give-my-money-to-the-bad-guys-OK button on a dialog).
You raise a good point. If DANE credential are available, then the target
of a connection has made an effort to be authenticated via a high-quality
mechanism. So some sort of error seems appropriate. This issue deserves
more attention.
> "PE" label for them to see?
I was alluding to the PR that is inevitably associated with this effort.
yep.
> correct).  Therefore we should not consider (3).
Not sure ow to interpret your last comment above. My suggestion was that #3
above was more indicative of a targeted attack, not PM, and thus we could
consider it a lower priority. Also,m it's largely outside the scope of what
we do in the IETF, where protocols to enable interoperability have been 
our primary
focus.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:58:29 -0400

Nico,

> marketing failure in our hands, and badly damaged reputation.
We have seen revelations that active attacks of the sort in my bullet
#2 have been employed. I was not suggesting that such attacks are out of 
scope,
but rather that if we choose to prioritize the set of attacks of 
interest, this
was a reasonable order.

We can give partial credit if we choose ;-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:58:59 -0400

DKG,

> here's my abbreviated take on the major complaints for existing
amen.
> in the crypto world, related to message integrity)
+1
> pervasive) any time soon.
I must point out that Stephen Farrell's I-D (soon to be RFC) notes
that pervasive is not the same a ubiquitous, so I don't agree that a
lack of encryption everywhere is a valid reason for rejecting this term.
> choosing keys, but also talking about the way those keys are used.
eh?
  good rationale, but it seems a bit too (something?)

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:59:04 -0400

Stephen,
> Do folks agree with that?
I failed to mention another reason I dislike "opportunistic
encryption" as our chosen term. When a colleague did a literature
search he found that a majority of about 70 papers in IEEE, ACM ,and
similar publications used this term as originally defined in 4322.
So it seems unreasonable (to me) that the IETF can unilaterally decide,
years later, to redefine the term.

Prior to the recent PM focus, I don't think this term was being used
commonly in the IETF. So, let's move beyond a 6-9 month infatuation with
a term that had been used in a technically inaccurate fashion and just make
up something new.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:59:07 -0400

Paul,
> Saying that the Postfix's community use of a specific definition of "opportunistic TLS" should trump the large value of having a single definition for "opportunistic encryption" feels somewhat self…
With all due respect, Michael gave up change control when the RFC was 
published. And, I noted
in a recent message, a larger community has used the term for a number 
of years, in a variety
of publications. While not all of them used the term in a fashion 
consistent with 4322, most
did.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Mar 2014 18:59:12 -0400

Stephen,

thanks.
> I also have a suggestion, just to see how it lands...
oh well :-(.
> for what I see most people talking about to be honest.
OK, I mean no problem ;-).
> because it would be possible to do mutual" is not where
I don't think I understand you comments above, but the
I-D was quickly revised and certainly needs work.
> doing key exchange and encryption at the opportune time in
I don't see that characterization as informative, but maybe
I;'m missing your point.
>     with endpoint authentication.
OK, now that I see text, I don't like it :-). "Opportune"
here does not seem meaningful to me.
>     relevant for the protocol concerned:
Oh, so you define "opportune" based on the characteristics
I cited later. Now I get your point, but I can't say that I
agree with it.
> fine. I'd be interested in more opinions on that issue.
I think we should honor the 4322 definition  for two reasons:
     - it describes a specific class of mechanisms that merits a
        unique, unambiguous term

     - the term has been used in the broader literature (not just
       I-Ds and RFCs, and the majority of the uses appear to be
       consistent with (and cite?) 4322. Thus if the IETF decides to
       redefine the term now, it sets a bad precedent.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Fri, 21 Mar 2014 20:06:29 -0400

> any written record of the earlier use by these folks?

http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/glossary.html#carpediem

Opportunistic encryption
    A situation in which any two IPSEC-aware machines can secure their communications, without a pre-shared secret and without a common PKI. This is a long-term
goal of the Linux FreeS/WAN project which we expect to acheive using Secure DNS.

http://www.freeswan.org/history.html

The idea is to deploy PC-based boxes that will sit between your local area network and the Internet (near your firewall or router) which opportunistically
encrypt your Internet packets. Whenever you talk to a machine (like a Web site) that doesn't support encryption, your traffic goes out "in the clear" as usual.
Whenever you connect to a machine that does support this kind of encryption, this box automatically encrypts all your packets, and decrypts the ones that come
in. In effect, each packet gets put into an "envelope" on one side of the net, and removed from the envelope when it reaches its destination. This works for all
kinds of Internet traffic, including Web access, Telnet, FTP, email, IRC, Usenet, etc.

---

From: Mouse <[email-masked]>
Date: Fri, 21 Mar 2014 20:48:09 -0400 (EDT)

>>> The trend is to reinvent the Internet at the app layer; [...]
>> This trend is a very, very good one.

Strong disagreement here.

The Internet was built with a lot of thought from a bunch of very very
smart people, many of whom made mistakes that needed to be fixed
despite being the best of the best.  Application-layer authors mostly
are not, nor ever will be, the best of the best.  If the Internet is
reinvented at the app layer, it will be reinvented many times, usually
badly, in incompatible ways.  Each reinvention will have new and
creative bugs at both code and protocol layers.  This strikes me as a
recipe for bad interactions, especially around reactions to congestion.

>> Are you familiar with mosh (http://mosh.mit.edu/)?  You should be.

I just read that page.  My reaction is a shudder and a burst of
gratitude that I don't have to deal with it.

Why?  A whole bunch of reasons.  Some of them, like its dogmatic
assumption that everyone wants (or can even tolerate) UTF-8, are not
relevant to saag.  But others, like its reinventing of reliable
transport atop UDP, are.  The webpage gives me no reason to think its
authors even _thought_ about congestion control, which makes me feel it
is nigh on certain that it either doesn't even try to react to
congestion or it gets it wrong.

And then there's their reaction to a reviewer.  Quoting from the
webpage:

> "ISO 2022 locking escape sequences oh flying spaghetti monster please
> kill me now." - actual USENIX peer review from the Mosh paper.

>    (Why you should trust Mosh with your remote terminal needs: we
>    worry about details so obscure, even USENIX reviewers don't want
>    to hear about them.)

...uh, guys, maybe it's just that you deserve to be panned?  This is an
amazing piece of spin-doctoring, to take a review that bad and respin
it as something positive.  I'm impressed, impressed that they thought
to do it, impressed that they came up with a way, impressed that they
had the sheer gall to try it...and very very impressed - negatively,
but impressed - that they did.

>> Mosh solves mobility... because TCP doesn't.  Because all relevant
>> IP mobility options are too complex, not in widespread use or
>> available, or have annoying trade-offs.

Unlike mosh, which...is too complex (predictive echo?? I'm amazed you
can imply it's not "too complex" with a straight face), not in
widespread use (if they have to trumpet individuals using it, it is not
in widespread use) or available (well, this one I'm willing to give
them), or has annoying trade-offs (reinventing TCP? no v6? no
forwarding? and those are just the ones that are obvious without even
trying to build-and-install it).

mosh really needs to die.  It needs to either use TCP or reconstruct
the whole of TCP atop UDP; if it can be a better TCP, the right answer
is to make TCP better and thereby allow _all_ applications to benefit;
if it can't, it's still better for it to use TCP.  The only thing
reinventing TCP atop UDP does for it is allow it to be more aggressive
about grabbing network resources in the presence of network overload -
ie, to be a greedily ill-behaved inhabitant of the network.  We need
fewer, not more, such.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Mar 2014 01:03:22 +0000

> I mean "can" there, and not "should, in my perfect world."

I was describing this discussion to a friend, and set that
opportunistic was doing a good job of capturing "as strong as
possible" encryption.  His comment was: "Why not call it ASAP
encryption", where ASAP is an acronym for "as strong as possible".

Can this gain consensus?  It has the advantage of no prior history,
and roughly the right semantics.  The disadvantage is that the
standard meaning of ASAP is different, and this is not as useful
for prepending to other terms, so for example, I don't see using
"ASAP DANE TLS".

So my vote is still for "opportunistic", but if "ASAP encryption"
takes the world by storm as the umbrella term, I can live with
that.

Given all the discussion here, it is difficult to imagine any one
choice getting universal approval.  How "rough" does rough consensus
need to be?

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 22 Mar 2014 08:08:41 +0100

> 	- minimally reliable security
Reliably means that users can rely on it and we don't want users to be involved.

> 	- minimal and reliable security (MARS)
Best effort alternative security topology - BEAST?

/O ;-)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 22 Mar 2014 12:16:42 -0400

On 03/21/2014 06:58 PM, Stephen Kent wrote:
> [dkg wrote:]

to clarify: if we opportunistically do key agreement between peers that
have never seen before, and then we use those keys for a MAC for our
session, we've now got cryptographically strong message integrity (the
usefulness of this is left as an exercise to the reader), but no
encryption.  This is arguably "opportunistic keying" but it doesn't
provide any resistance against pervasive monitoring.

	--dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Mar 2014 17:57:32 +0000

> >"Opportunistic encryption" isn't ideal because it has other historic

I have a suggestion that might help get us out of the rut, we could use:

	opportunistic security

rather than overload the existing,

	opportunistic encryption

to which the principal objection seems to be prior use with IPSEC
to mean something more specific than the intended umbrella term.

OBSERVATION:

    The reason the adjective opportunistic is such a good fit for many
    of the nouns in this space, is that hints at without specifically
    promising two different aspects of taking maximizing advantage of
    opportunity:

	- Whenever possible.

	- As strong as possible.

    Many of the proposed alternatives miss one or the other or both aspects
    desirable in the umbrella term.  Thus for example "pervasive" does not
    suggest maximizing strength, ASAP focuses only on strongest possible,
    ...

    For example, "opportunistic TLS", is primarily unauthenticated
    TLS whenever possible (not necessarily strong, but best effort),
    while "opportunistic DANE TLS" maximizes opportunity to take advantage
    of DANE authentication in a downgrade-resistant manner.  This is
    both as strong as possible, and whenever possible.

So unless a miracle happens, I don't see a better adjective coming our way.
If broadening the IPsec term is to be a sticking point (it does not seem
such an insurmountably compelling precedent to me), perhaps we can keep
"opportunistic" which IMHO fits like a glove and change "foo"?

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 23 Mar 2014 16:44:23 +0800

> to mean something more specific than the intended umbrella term.

I still *prefer* "opportunistic encryption" (I think that the folk
that already know the term are bright enough to not get confused by
the new usage (or are already involved in this discussion :-P), and
the ones who don't know it will grok the meaning), but "opportunistic
security" is the best alternative I've heard...

W

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Mar 2014 18:09:58 -0400

> any written record of the earlier use by these folks?

As Paul pointed out, and is in the references for 4322, the entire system was
described in a document formerly known as "opportunism.spec":
    http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/opportunism.spec

which later was renamed.  I'm sure it's in the 1.5 and earlier trees, but
maybe I'm wrong.

and also:
http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/overview.html

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Mar 2014 11:51:23 -0400

Viktor,

> I have a suggestion that might help get us out of the rut, we could use:
this work for me, as does your later suggestion of ASAP.

Steve

---

From: Ira McDonald <[email-masked]>
Date: Mon, 24 Mar 2014 11:54:50 -0400

Hi,

I prefer the suggestion for ASAP (a positive term).  In modern English
"opportunistic"
is typically negative and also conveys "untrustworthy" - which is the
opposite of the
intent here.

Cheers,
- Ira

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Mar 2014 11:55:21 -0400

Michael & Paul,

Thanks for pointing out the reference [OEspec] I had overlooked in 4322.

I'll revise the I-D to reflect that earlier doc (BTW, the link in 4322 
doesn't work
anymore).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Mar 2014 12:14:03 -0400

DKG,

> provide any resistance against pervasive monitoring.
Good point.

So let's forget about opportunistic keying.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Mar 2014 16:20:55 +0000

Hi all,

> this work for me, as does your later suggestion of ASAP.

Me too, or at least good enough.

I'd say let's let Steve update the I-D that way and then
we can hopefully work on the other text and get done
soonish.

S

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Mar 2014 16:23:33 +0000

> Do folks agree with that?

I think we have an answer to this one, which is that we
will end up using the word opportunistic.

And Steve's said he'll update the I-D to see if the
term opportunistic security works as our preferred term.

So let's call this particular question closed and see
how it looks when we have a -01 draft and go from there.

Thanks,
S.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Mar 2014 13:30:11 -0400

redefining the acronym ASAP seems unwise. It will always stand for As Soon As Possible no matter what a bunch of security geeks say it means.

Paul

---

From: Mouse <[email-masked]>
Date: Mon, 24 Mar 2014 14:37:36 -0400 (EDT)

> redefining the acronym ASAP seems unwise. It will always stand for As Soon A$

To a point, of course.  But there _is_ prior art for other uses; I know
someone who was working on a Linux distro called ASAP, which IIRC stood
for Another Slackware Alpha Port.

I feel reasonably sure the name was chosen to play on the common
meaning of the term, but still, it is something like precedent.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign