Subject: [ietf-privacy] "Opportunistic encryption" and a need for a definition

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Nov 2013 10:33:43 +0100

[Long quiet time on this list, time to resume discussions.]

In draft-cooper-ietf-privacy-requirements-01, I find:

   "Opportunistic encryption" is defined as encryption without any pre-
   arrangement specific to the pair of systems involved (e.g., by using
   a Diffie-Hellman exchange).  See [RFC4322].

I find this definition confusing (specially the reference to DH)
because it does not match the rest of the text which says:

   Where both opportunistic and one-sided or mutually
   authenticated encryption are specified, protocols MUST also protect
   against downgrade attacks so that scenarios where authentication is
   required cannot easily be manipulated into using opportunistic
   encryption which will often be subject to man-in-the-middle
   attacks.

The second paragraph seems to use OE as meaning "encryption without
authentication" (which is indeed vulnerable to man-in-the-middle
attacks). This is also how "opportunistic" is used in RFC 5386.

The first paragraph (and RFC 4322) have a different meaning, OE being
"encryption without peer-specific setup" (and therefore being
authenticated, and not vulnerable to man-in-the-middle attacks).

The discussions in Vancouver were very confused as well. Everyone was
talking about OE but with a different definition in mind. I strongly
suggest that we need either to have one definition and to stick with
it (the current draft is self-contradictory). Or to give in and to
stop using the term OE, poorly defined, and too loaded.

Do not that Wikipedia has a third definition of OE (encryption with a
fallback to an unencrypted
mode) http://en.wikipedia.org/wiki/Opportunistic_encryption

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Nov 2013 10:39:00 +0100

Stephane,

I agree that OE has been used in several different ways, and I suggest
that in fact there are several different forms.  It is likely the case
that no one form will fit all uses.  As such, it's a good opportunity
for an informational document.  In fact, I've suggested to several
people that they take this on.

Eliot

On 11/19/13 10:33 AM, Stephane Bortzmeyer wrote:
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Nov 2013 10:46:26 +0100

On Tue, Nov 19, 2013 at 10:39:00AM +0100,
 Eliot Lear <[email-masked]> wrote 
 a message of 55 lines which said:

> in fact there are several different forms.

I find three:

1) Encryption without a peer-specific arrangement. This is the meaning
used in RFC 4322. Can be safe.

2) Encryption without authentication. This is the meaning used in RFC
5386. Safe only against a purely passive attacker.

3) Encryption with a fallback to unencrypted mode. This is the
Wikipedia definition. Certainly unsafe.

draft-cooper-ietf-privacy-requirements-01 mixes 1) and 2)

> As such, it's a good opportunity for an informational document.

Volunteers are welcome to start from the list above :-)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Nov 2013 10:04:00 +0000

Hiya,

> used in RFC 4322. Can be safe.

So I (1) that to mean that there's a not-so-secure way to
validate that the right key for a peer is being used, in
4322 via DNS without DNSSEC. Adding DNSSEC gets you beyond
OE I'd say.

> draft-cooper-ietf-privacy-requirements-01 mixes 1) and 2)

That's a fair comment. Since the draft is calling for a minimum
I think (2) is more appropriate for now since there will be some
places where its not feasible to get (1).

When we push out another rev, we'll make that clear, specific
text suggestions are welcome too of course.

> Volunteers are welcome to start from the list above :-)

Actually, I'd like (if possible) to go a bit further than
simply definitions, I think the info document we want is
a "HOWTO pimp my protocol with OE" spec, but for that to
be done well, I think we need an author or two who's recently
e.g. implemented ECDH in protocols. I've asked someone but
they're busy, if you know someone who could do that then
either twist their arm yourself or point me at 'em. (Or if
that describes you, then either write something or get in
touch with me.) Trying to get an implementer like that does
make it a bit harder to get started, but if the resulting
RFC is to be really useful, I think it'll need to be fairly
high quality since it could end up being used in lots of
protocols, probably via ^C^V, so getting it right will be
more important than usual perhaps.

Cheers,
S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Nov 2013 11:06:54 +0100

On Tue, Nov 19, 2013 at 10:04:00AM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 66 lines which said:

> When we push out another rev, we'll make that clear, specific text
> suggestions are welcome too of course.

My suggestion is to stop completely to talk about opportunistic
encryption.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Nov 2013 11:24:50 +0100

So here's my pet peeve:

> My suggestion is to stop completely to talk about opportunistic

OE may have other very valid uses besides pervasive surveillance,
depending on its definition.  One of the problems that has beguiled home
networking people is how to establish a trust between devices in the
home.  There are similar cases for home access beyond the home, where
trust needn't be anchored by an X.509 cert but perhaps by local
attestation of some form.  Are these use cases OE or is that not OE?

Eliot

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Nov 2013 11:28:21 +0100

On Tue, Nov 19, 2013 at 11:24:50AM +0100,
 Eliot Lear <[email-masked]> wrote 
 a message of 20 lines which said:

> OE may have other very valid uses 

The problem is not with the concept, it is with the
words. "opportunistic encryption" is used in many places but poorly
defined and many fights erupt because people do not actually
understand the same thing when they hear "opportunistic encryption".

What I suggest is to stop using this terme and instead to say:

1) "Encryption on demand" Encryption without a peer-specific
arrangement. This is the meaning used in RFC 4322. Can be safe.

2) "Encryption without authentication". This is the meaning used in RFC
5386. Safe only against a purely passive attacker.

3) "Encryption with a fallback" (to unencrypted mode). This is the
Wikipedia definition. Certainly unsafe.

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Nov 2013 07:58:05 -0500

Eliot, I wouldn't say it's OE because local attestation is a solid form of
authentication.  I like Stephen 's suggestion: roll solving this ambiguity
into work on the pimping cookbook.

Scott
So here's my pet peeve:

Eliot

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Nov 2013 16:20:27 -0600

> attestation of some form.  Are these use cases OE or is that not OE?

Not OE. That’s more like low-configuration-overhead authentication.

—
Dean

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Nov 2013 18:26:27 +0000

> arrangement. This is the meaning used in RFC 4322. Can be safe.

I believe that this is what 4322 calls an "opportunistic tunnel" as compared to a "configured tunnel". Is there a reason to call it something else?