Subject: Re: [saag] Fwd: Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 10:54:07 -0700

I didn't see the post on the main list, but my view is that this doc 
needs to be handled in SAAG. I do not support its moving forward as an 
individual draft.

Joe

On 7/8/2014 8:34 AM, Stephen Farrell wrote:
>
> IETF LC started as promised.
>
> Cheers,
> S.
>
>
> -------- Original Message --------
> Subject: Last Call: <draft-dukhovni-opportunistic-security-01.txt>
> (Opportunistic Security: some protection most of the time) to
> Informational RFC
> Date: Tue, 08 Jul 2014 08:09:40 -0700
> From: The IESG <[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce <[email-masked]>
>
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Opportunistic Security: some protection most of the time'
>    <draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-08-05. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This memo defines the term "opportunistic security".  In contrast to
>     the established approach of delivering strong protection some of the
>     time, opportunistic security strives to deliver at least some
>     protection most of the time.  The primary goal is therefore broad
>     interoperability, with security policy tailored to the capabilities
>     of peer systems.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
> This document and a predecessor have been the subject of discussion
> on the saag mailing list. [1]
>
>      [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html
>
>
>
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 20:03:18 +0100

Hi Joe,

> needs to be handled in SAAG. I do not support its moving forward as an

saag is not an area working group, so cannot do that. Its
just not the same setup as with appsawg for example.

And I'm not clear what difference that'd make either,
especially since this topic, and, more recently, this draft
have been the subject of significant discussion on the saag
list.

Cheers,
S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Jul 2014 12:06:19 -0700

> have been the subject of significant discussion on the saag

The draft proffers definition of a term that has become central to some
recent IETF work.  We need a single definition about which there is
strong community agreement.

The topic has had lively and extended discussion through the saag
mailing list, with at least one competing effort (from Steve Kent.)

Developing and indicating the degree of rough consensus about this draft
from the saag list would indicate the extent to which that discussed
converged.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 12:53:49 -0700

> just not the same setup as with appsawg for example.

That's unfortunate; it would be useful to have this have a home within 
the IETF.

> have been the subject of significant discussion on the saag

Yes, but there was no "WGLC". Jumping straight to IETF LC seems like an 
end-run around this being homed in a WG - any WG - and IMO it ought to be.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 13:19:15 -0700

On 7/8/2014 1:09 PM, Nico Williams wrote:
> What's the problem?  How has the process been circumvented, in its
> letter or spirit?
>
> Nico

I guess the spirit; I had thought that the security community within the 
IETF had a more formal process for defining new terms, but also note 
that its glossary is "Informational" (not BCP).

So I withdraw that aspect of my objection; I'll post on the content 
separately.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jul 2014 16:51:44 -0400

Nico Williams <[email-masked]> wrote:
    >  - The individual submission track exists in part for just this sort of
    > I-D.

I think that is actually an AD-sponsored draft, which is a different stream
again (with less friction).

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

---

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Jul 2014 13:54:37 -0700

Hello,
>[email-masked] mailing lists by 2014-08-05. Exceptionally, comments may be

According to the Abstract the memo defines the term "opportunistic 
security".  The Introduction section provides some information about 
the issues with key management.  If I understood correctly, 
opportunistic security is about employing as much security as 
possible, without falling back to unnecessarily weak options.  In 
other words, it is about not requiring authentication when key 
management is not possible.  I would ask why not trust on first use 
(mentioned in Section 1).  The argument in the memo is that it does 
not provide any authentication for the first contact.  However, what 
it can convey is that the "other end" I am attempting to communicate 
with is not the same as the one I communicated with for the first 
contact.  Does that make nation-state monitoring less 
easy?  Yes.  I'll note that the facilities which were compromised had 
the ability to implement key management.

Does trust on first use maximize deployment (see Section 2)?  The 
short answer is yes.  Does it scale?  I do not think so.  It can be 
argued that the 99% is being protected from monitoring.  It is the 1% 
which might be of interest.

Is security maximized peer by peer?  The short answer is yes.  Does 
it scale?  I do not think so (see above).

 From Section 2:

   "An opportunistic security protocol MUST interoperably achieve at
    least unauthenticated encryption between peer systems that don't
    explicitly disable this capability."

Isn't opportunistic security a design philosophy instead of a protocol?

As a nit, the RFC 2119 boilerplate appears in Section 3.

I suggest not representing opportunistic security as strong 
security.  The fourth paragraph in Section 2 does not say that clearly.

   "Some sending MTAs employing STARTTLS have been observed to abort
    TLS transmission when the receiving MTA fails authentication,
    only to immediately deliver the same message over a cleartext
    connection."

During an unrelated discussion John Klensin pointed out that I did 
not take into account that SMTP is hop by hop.  In the example quoted 
above the receiving MTA might not be providing opportunistic security.

   "This design blunder MUST be avoided."

I am not enthusiastic about using RFC 2119 key words to say that.

 From the Security Considerations section:

   "Though opportunistic security potentially supports transmission in
    cleartext"

There is the following in Section 1:

   "Opportunistic security encourages peers to employ as much security as
    possible, without falling back to unnecessarily weak options."

I consider "clear text" as a weak option.  The two sentences quoted 
above differs in the interpretation of opportunistic security.

As the intended status is Informational I am okay with publishing this memo.

Regards,
S. Moonesamy

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Jul 2014 08:16:09 +0900

i have read this draft and followed the discussion on saag.  i think it
is needed and worthwhile contribution.  while i am especially fond of
encrypt by default, it is important that inability to authenticate must
not lead to cleartext when unauthenticated encryption is possible.

randy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Jul 2014 10:48:00 +0200

Dear IESG,

I have a question and several comments (with proposed edit) for your and
the author's consideration.

First, and most abstractly, this document defines opportunistic security
solely in terms of encryption.  Indeed Section 2 states:

   In summary, opportunistic security is an umbrella term that
   encompasses protocol designs that remove barriers to the widespread
   use of encryption in the Internet.

My question: are there other forms of opportunistic security that this
definition would foreclose?  For example, might taking advantage of
physical presence also be a form of opportunistic security?

Second, the abstract doesn't match the document.  The abstract states
that "This memo defines the term "opportunistic security".  It goes much
further than defining that term.  Rather it specifies requirements for
and characteristics of opportunistic security, complete with normative
language.  My suggestion would be to restate the abstract as follows:

OLD:

NEW:

   This memo defines the term "opportunistic security" and its attributes,
   and specifies requirements for implementing it in IETF protocols.  In
   contrast to the established approach of delivering strong protection some
   of the time, opportunistic security strives to deliver at least some
   protection most of the time.  The primary goal is therefore broad
   interoperability, with security policy tailored to the capabilities
   of peer systems.

If people think the word "requirements" is too strong, then perhaps
"guidance".  Given the use of normative language, you may also wish to
consider making this document a BCP and reviewing it in that light.

Finally, an editorial nit: I suggest that the 2119 boiler plate be moved
up to prior to first use of 2119 normative language (like bottom of
Section 1).

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Jul 2014 12:27:18 +0100

Hi Eliot,

Just on processy points... ;-)

On 09/07/14 09:48, Eliot Lear wrote:
>  Given the use of normative language, you may also wish to

We (the IETF:-) agree that one can use 2119 language in informational
RFCs, as we do it all the time:-) In this case, I think myself that
the 2119 language isn't really needed but I raised that on the saag
list and nobody seemed to have a problem with it as Viktor has it,
and I don't feel strongly about it. (I only raised it in the hope of
not having to talk about 2119 during IETF LC:-)

On the BCP thing, I think that would be a mistake, for now, for this
document. This is really just defining and describing OS so that other
protocols can more easily use that technique, should they want to,
without having to argue terminology and re-define the basic concept
over and over with minor and subtle variations being likely each time.

So for example, in the httpbis wg case this document would mean the
wg wouldn't have had to have had the "what is OS and is it ever a
good thing?" discussion, but they still would've had to figure out
whether and how to use OS in e.g. HTTP/2.0. (As has happened, and
is getting close to done I think.)

Later, I think we may want to provide guidance about when to use OS
and when not, and that's when I figure the BCP part of the OS story
would get done. For that I think we need to learn from what's
happened in e.g. the httpbis wg and elsewhere, so I figure we're
not there yet. And even though we do IMO have a really good success
story for OS with recent deployments of STARTTLS for MTA-MTA SMTP,
it'll be interesting to see if the non-authenticated cases there
transition towards authenticated endpoints or not over time so we
might be better off waiting a while to find out stuff like that
before writing BCP text.

Cheers,
S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 Jul 2014 05:57:34 -0700

> again (with less friction).

I think Individual Submission and AD-sponsored are the same thing.  Perhaps
you're thinking of Independent Submissions?

If this has been thoroughly discussed in SAAG (I haven't checked) but
doesn't have a working group, then the Individual route is absolutely the
right way to go.  The alternative is a route that doesn't have IETF
consensus, which strikes me as just wrong here.

-MSK

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Jul 2014 15:17:00 +0200

Hi Sam,

On 7/9/14, 3:05 PM, Sam Hartman wrote:
> I support the 2119 language in this document.
> I prefer that it not be removed.
>
>

Who suggested its removal?

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Jul 2014 14:19:22 +0100

> Who suggested its removal?

Me:-) On the saag list. But just suggested as a personal
preference. I'm ok with it staying too.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Jul 2014 13:49:42 +0000

On Wed, Jul 09, 2014 at 12:27:18PM +0100, Stephen Farrell wrote:

> And even though we do IMO have a really good success

Transition to PKIX authentication is unrealistic for SMTP.

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10#section-1.3

so any large-scale use of authenticated STARTTLS with SMTP is
predicated on DANE adoption, which is predicated on DNSSEC deployment.

While I am hopeful that the pace DNSSEC adoption will pick up, this
will take some time.  It would help if more applications than a
single MTA took advantage of DANE, motivating broader DNSSEC adoption.

The SMTP problem is generic to any protocol that is opportunistic
and uses DNS indirection (MX, SRV, ...).

Thus, while Facebook's SMTP security report seems to suggest that
they expect or hope for SMTP authentication via CA certificates to
become more prevalent, they are misguided.  PKIX CA authentication
with SMTP without per-destination manual settings gives at best
illusory security.  There is little point in deploying public CA
issued certs on public MX hosts unless one has static reciprocal
authentication arrangements with partner domains.

-- 
	Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Jul 2014 09:05:00 -0400

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 Jul 2014 15:09:49 -0500

On Tue, Jul 8, 2014 at 2:53 PM, Joe Touch <[email-masked]> wrote:
> That's unfortunate; it would be useful to have this have a home within the
> IETF.

It works for apps, it could work for us, but I think that's not
something we're going to deal with in this thread -- start a new
thread?

> end-run around this being homed in a WG - any WG - and IMO it ought to be.

Not really:

 - WGLC is two weeks, and IETF LC is two weeks when the I-D was
WGLCed, but for individual submissions the IETF LC is four weeks.
Reviewers have the same amount of time in either case.

 - The security community, through saag, is *clearly* aware of this I-D.

 - There's no WG whose charter this I-D could have fit into.

 - There's no WG whose charter could reasonably have been modified to
fit this I-D.

 - Having a BoF to start a one-document WG would have been a misuse of
resources.

 - The individual submission track exists in part for just this sort of I-D.

 - You yourself are aware of the I-D and, like everyone else, have
four weeks to review.

 - The IESG gets a crack at this I-D as well.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 Jul 2014 15:49:30 -0500

On Tue, Jul 8, 2014 at 3:19 PM, Joe Touch <[email-masked]> wrote:
> IETF had a more formal process for defining new terms, but also note that
> its glossary is "Informational" (not BCP).

We don't have a single set of terms that everyone uses.  The
terminology used in the space of GSS, SASL, Kerberos (these three all
in one WG now), IPsec, TLS, SSHv2, EAP, and so on all differ,
sometimes subtly, sometimes radically.

Unifying our sets of terminology would be so difficult as to be
impossible, except over time, by piecemeal adoption of new terms.
Adding new terms that we can all use is much easier, and given the
state of play, shouldn't really require heavy-duty process --
otherwise we couldn't even make piecemeal progress as to common
terminology.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 Jul 2014 16:16:38 -0500

> again (with less friction).

Yep, right you are.

---

From: Niels Dettenbach <[email-masked]>
Date: Wed, 09 Jul 2014 23:12:28 +0200

Am Mittwoch, 9. Juli 2014, 13:49:42 schrieb Viktor Dukhovni:
> illusory security. 
+1
but this is what Facebook a.s.o. might be interested in - they are still 
"have" / "know" the "real" "communication contacts" of peoples which could 
they sell / serve for this application in a "next level" WhotsUp or 
similiar...

just my two cents...

Niels.

-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Jul 2014 21:45:45 -0400

Umm every major email client already has STARTTLS using PKIX Authentication
using the WebPKI roots. Go take a look at them.

So how can it be impractical to do something that has already been routing
for over a decade?

You might well want to apply a security policy grounded in DNS and you
might well choose DANE/DNSSEC for that but you could equally do DANE on its
own or inband signaling such as pinning.

Yes, I know that the STARTTLS draft does have a confused statement on the
subject ruling out use but that doesn't mean it is correct and it has been
routinely ignored in the major implementations because they were using
WebPKI client side before STARTTLS was proposed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Jul 2014 01:51:32 +0000

> using the WebPKI roots. Go take a look at them.

The MUA-to-MTA use-case is completely different.  I am not talking
about the MUA-to-MTA use-case.

> So how can it be impractical to do something that has already been routing

Easy, we're talking about completely different things.  MUAs are the
most robust use-case for PKIX, because they are statically configured
to use a single MSA.  MTAs are the least compatible with PKIX, because
of MX indirection, lack of user-clicks-OK fallback and need to send
email to every dark corner of the internet.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 02:58:04 +0100

On 10/07/14 02:51, Viktor Dukhovni wrote:
> MUAs are the
> to use a single MSA.

Even that is a PITA though. If I setup a domain with mail then
I think in most cases I pretty much have to deal with the MUA
getting a certificate warning of some sort when connecting to
the MS and where that cert warning is essentially meaningless.
In other words, I agree with Viktor that we're talking about >1
radically different scenario (in terms of TLS or the UTA wg.).

S.

---

From: [email-masked]
Date: Wed, 09 Jul 2014 19:06:44 -0700 (PDT)

> about the MUA-to-MTA use-case.

Quite right.

And FWIW, we have long made a distinction here at protocol level. The
MUA-to-MTA case is called "message submission", often abbreviated as "submit",
and happens on port 587. The MTA-to-MTA case is called SMTP, and happens on
port 25.

Although the base protocol is the same, the extensions defined for SUBMIT and
SMTP are also different.

It's really confusing to use the term SMTP to refer to message submission.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 Jul 2014 08:29:49 +0100

> So how can it be impractical to do something that has already been routing
Also, XMPP has almost the exact same set of problems as (MTA/MTA) SMTP, and
seems to have deployed TLS with PKIX auth just fine, and the deployed
network is shifting with some pace toward this being mandatory.

The only additional issue for SMTP is that you'd need SNI, but that's not
terribly onerous these days.

Dave.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Jul 2014 08:53:27 +0000

On Thu, Jul 10, 2014 at 08:29:49AM +0100, Dave Cridland wrote:

> seems to have deployed TLS with PKIX auth just fine

This is a dramatic over-simplification.

> and the deployed

TLS yes, PKIX authentication, not so much, and only provides security
when the XMPP server can obtain certificates for the target domain
(not the SRV host).  With SMTP third-party MX hosting is rather common,
and makes the latter substantially more difficult.

> terribly onerous these days.

This is also a dramatic over-simplification.  SNI support is easy,
cross-domain key management is not, and other barriers remain.
Since this is a distraction, I will not debate it further point by
point.

-- 
	Viktor.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 Jul 2014 10:13:39 +0100

> This is a dramatic over-simplification.
That's your subjective opinion, and I think it's wrong.

> TLS yes,

With you so far.

> PKIX authentication, not so much,

No, there really is a serious deployed base of XMPP servers running with
valid, authenticatable certificates. There are a number of servers deployed
which require authentication by certificate alone, and they do just fine,
unless you want to talk to XMPP service providers who don't care about
interop and/or security (like Google).

> and only provides security
> (not the SRV host).

... which is the norm, for XMPP. However your statement is somewhat
incorrect; if DNSSEC is deployed and the SRV/MX RR is secured, the hostname
can be used as a reference name just fine. No loss of security.

DNSSEC deployment is on the rise within the XMPP world, though support
isn't yet well implemented.

> With SMTP third-party MX hosting is rather common,

Here I tend to agree, however that doesn't mean that the whole of PKIX is a
lost cause. Not only is there the DNSSEC option as described briefly above,
but service-restricted certificates (using sRVName, for example) should
mitigate much of the concerns anyway. It's unfortunate that the CA industry
seems to assume that any use of Subject Alternate Names is a premium
service that should be charged at ten times the rate, of course.

I'd note that these concerns exist, albeit to a generally reduced degree,
within the XMPP world.

Mind you, they also exist in the HTTP world, but for some reason I cannot
fathom, everyone appears to tacitly ignore them there.

> Since this is a distraction, I will not debate it further point by

I don't think it's much of a simplification at all - the differences are of
degree, not form.

The major barrier that exists is in the required global uplift in security
- the XMPP community is rather smaller, and more tight-knit than the mail
community. But this problem exists for purely DANE-based solutions as well.

Dave.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Jul 2014 13:56:53 +0200

Gents,

The thing about XMPP is that the ecosystem is probably 2 - 3 orders of
magnitude smaller than that of SMTP, and there are some very big players
that can help move things along, like Google, FB, to name two.  With
SMTP, there are tens of thousands of MTAs, and that means that red flag
days along the lines of what Peter made happen (!!) gets harder to do.

Also, I would be curious of how often a crypto set failure happens with
email, given how much old software would linger.  Would people care?

IMHO that makes you both right ;-)

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Jul 2014 10:18:53 -0400

> This is a dramatic over-simplification.

Not really, when you state that something is impossible then the fact that
you have ignored the fact people have being doing it for over a decade you
are the one making the 'dramatic oversimplification'.

MUA to MTA is not really as different from a trust perspective as you
imagine. The problem is the lack of a security policy infrastructure. But
that has already been added to HTTP for HTTPS with pinning and it could be
added to SMTP in the same way. To deny those possibilities with a wiff of
the hand is dramatic oversimplification.

There is a huge amount of specious anti-CA babble that goes on in this
forum and a distinct disinterest in comparing like with like. For example
lets take Heartbleed, an attack that was orders of magnitude more serious
than any CA error apart from DigiNotar. But have people concluded that we
can't trust open source software at all? There was the Apple issue that led
to a huge exposure but nobody suggested defenistrating Safari.

The CA security model I and others developed in the late 90s was always
predicated on the idea that revoked certificates would result in a
hardfail. The browser providers decided that the CA validation processes
were sufficiently strong that softfail is sufficient. But nobody seems to
want to hold them accountable for the consequences of that short cut.

I find the special pleading that goes on here to be rather irritating. Can
we please get back to (or start) making engineering decisions on an actual
engineering basis not some ideology about what the best PKI is.

Right now the WebPKI is the only one we have got and that is likely to
remain the case for quite a while, at least as far as the server side goes.
Which is a pity as DNSSEC which requires far more active management than a
PKIX certificate is potentially a major business opportunity for CAs.

I am not at all opposed to 'free' PKIs. In fact the day before Toronto
starts I will be in NYC with Ellsberg, Snowden et. al. launching a personal
PKI that does not require anyone to pay anyone to manage it.

You see at the end of the day any crypto geek worth their salt is going to
be charging $200/hr to set up a PKI and an InstantSSL cert from Comodo
costs $65 and comes with support. And its easier to find my product than
find a crypto-geek to configure a 'free' PKI. And anyone who tries to
manage free PKIs in bulk is going to build something that looks like our
operation or our competitors.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Jul 2014 14:27:01 +0000

On Fri, Jul 11, 2014 at 10:08:59AM -0400, Rene Struik wrote:

> One of my concerns with Optimistic Encryption is that it may have as side

	s/Optmistic/Opportunistic/

> effect that it may be tempting for implementers to move from secure and
> authentic channel set-up to just encrypted (but unauthenticated) channels,
> since it - how convenient - removes the need for any admin...

Unauthenticated encryption is only appropriate where no current
key management approach scales.  If unauthenticated encryption is
employed within an organization, that's a security failure that
needs to be addressed by the organization's IT team.

In parallel with advancing opportunistic security at Internet scale,
we need to improve key management at enterprise scale.  Make Kerberos
easier to deploy.  Make internal DNSSEC easier to deploy (and publish
SSHFP and DANE TLSA records, ...).

Making security ubiquitous is a battle on multiple fronts.  I am
hoping to define opportunistic security without mapping out the
whole security landscape.  Perhaps the larger landscape is a
different document?

Opportunistic security is intended to strengthen SMTP, HTTP and
the like, not weaken enterprise applications or industrial control
systems.

I don't think the opportunistic security definition promotes sloppy
internal risk management.  However, if this is felt to be important
to state explicitly, I think a sentence or two along those lines
might be acceptable in the security considerations section.

-- 
	Viktor.

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Jul 2014 10:08:59 -0400

Dear colleagues:

One of my concerns with Optimistic Encryption is that it may have as 
side effect that it may be tempting for implementers to move from secure 
and authentic channel set-up to just encrypted (but unauthenticated) 
channels, since it - how convenient - removes the need for any admin... 
I can already see arguments about why one should spend money on 
authentication support if the attack window is so small, etc., akin to 
discussions I have seen rampant in industrial control settings, where 
some people have argued that communicating symmetric keys wirelessly 
over the air for bootstrapping is okay, "since nobody would listen in 
anyway". I think this is a major risk.

If this "substitution risk" would materialize, we might actually lower 
the bar  and set back the clock nearly 40 years, since realizing 
encrypted, unauthenticated  channels already proposed in the 1976 paper 
on "New Directions in Cryptography".

Shouldn't one at least add some more extensive verbiage about security 
policy enforcement? After all, reason to do authentication would be to 
have some evidence on the party one is communicating with and can then 
arrive at more fine-grained conclusions as to authorization and scope 
hereof, based on that evidence.

The the day-to-day risk for security architectures may be increase of 
admin cost if there would ever be a lifecycle event after initial 
provisioning and where lack of authentication may really hurt.

Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Jul 2014 10:10:47 -0400

Sorry - "optimistic encryption" should read "opportunistic security" 
(although, perhaps, captures this as well...)

On 7/11/2014 10:08 AM, Rene Struik wrote:
> side effect that it may be tempting for implementers to move from 
> secure and authentic channel set-up to just encrypted (but 
> unauthenticated) channels, since it - how convenient - removes the 
> need for any admin... I can already see arguments about why one should 
> spend money on authentication support if the attack window is so 
> small, etc., akin to discussions I have seen rampant in industrial 
> control settings, where some people have argued that communicating 
> symmetric keys wirelessly over the air for bootstrapping is okay, 
> "since nobody would listen in anyway". I think this is a major risk.
>
> encrypted, unauthenticated  channels already proposed in the 1976 
> paper on "New Directions in Cryptography".
>
>>      [1] 
>> https://www.ietf.org/mail-archive/web/saag/current/maillist.html
>>
>>
>>
>>
>>
>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Jul 2014 10:33:47 -0400

The definition does not promote sloppy risk management, its use may (history of practical use of security is embarassingly full of sloppiness and taking shortcuts).

Rene

==

---

From: Dan Wing <[email-masked]>
Date: Fri, 11 Jul 2014 17:11:52 -0700

> and makes the latter substantially more difficult.

It seems POSH (*) could be applied to SMTP?

(*) http://tools.ietf.org/html/draft-ietf-xmpp-posh

-d

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 18:19:34 -0400

>   <draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
...
>    This memo defines the term "opportunistic security".  In contrast to

This document will be important.  Overall, it is a reasonable discussion
of a timely and useful construct.  It's basic organization and basic
writing are reasonable, although it does need additional and diligent
wordsmithing. (I will send those suggestions to the author separately.)

However the document is not yet ready for publication.  It suffers a
number of significant deficiencies that need to be remedied.  I believe
all of these have been cited by others, but here are my characterizations:

   1.  In a technical context the word 'security' is, at most, an
umbrella term that encompasses a range of possible capabilities, such as
integrity, authentication, encryption and so on.  By itself, the word
has no technical meaning, other than as a reference to an "area" of
technical work.

       Consequently the term "opportunistic security" falls somewhere
near the intersection of meaningless, confusing and wrong.  We do not
serve technical or non-technical communities well by using terminology
that is so vague or misleading (or both.)

       The actual focus of the draft is encryption and -- unless I've
significantly misread the draft -- the term that covers what is
discussed therefore should be "opportunistic encryption".

       I believe at least one other note did raise the possibility that
the term might /also/ include authentication -- distinct from
encryption.  While that's a reasonable idea on its own, it does not
appear to be consonant with any of the discussion around opportunistic
encryption.  So I suggest it be deferred.

       The topic of this draft needs to be changed to "opportunistic
encryption".

   2.  The document says it is providing a definition, but it does not
do that.  It needs to.

       What it does do is to provide an extended discussion of the
topic.  The discussion is useful, but it is not a definition.

       Viktor has commented on this concern with:

       > The definition is a summary of the design principles.

      This is the second major security-related document to assert such
a philosophy for a denotation exercise.  However a definition is a few
sentences; it is not multiple pages.  When the text gets into multiple
pages, it is a specification or a discussion.  It is not a definition.

      Fortunately, the draft provides some text that looks like a good
basis for a definition, which I've mildly reworked into:

         Opportunity encryption is an umbrellas term for efforts
         to increase the use of encryption by permitting variable
         protection strength during a session. It attempts to use
         the strongest capability possible, but permits falling back
         to a weaker option. In particular it permits the use of
         unauthenticated encryption when authentication is not
         available.

The phrasing "variable protection strength during a session" probably
needs improvement...

   3.  The draft variously permits or prohibits use of cleartext within
the context of the defined term.  This needs to be resolved, and carefully.

       My own sense from the saag discussions and the draft is that
there is tendency to conflate 'what opportunistic encryption is' with
'what is permitted in a session that attempts opportunistic encryption'.
 It other words, it is confusing the thing with the context in which the
thing is occurring.

       For simplicity and utility, I suggest that the term opportunistic
encryption always refer to actual encryption, with the note that when no
encryption is possible in a /session/ it might be permitted to fall back
to cleartext.

   4.  The draft's references to authentication are almost certainly
meant to be limited to server-side authentication.  That is, the
authentication that is attempted is of the side being contacted.  As I
understand actual Internet practices, mutual or client authentication is
typically NOT part of the process when setting up authenticated
encryption.  This needs to be clarified in the text.

   5.  The document uses the term 'strong' as a form of protection, but
doesn't really define it. However it seems to be used with some
significant meaning intended.  The term gets used frequently an casually
about security, but here it seems to be intended to have a specific
meaning.  That meaning should be provided explicitly.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Jul 2014 01:43:04 +0000

> that is so vague or misleading (or both.)

The term "opportunistic security" is defined as an umbrella term,
so if "security" is an umbrella term, there is no conflict.  I
should note that "TLS" is "transport layer security", not "transport
layer encryption", and TLS also can be used for a range of capabilities
ranging from:

    $ openssl ciphers -v 'eNULL+aNULL'
    AECDH-NULL-SHA          SSLv3 Kx=ECDH     Au=None Enc=None      Mac=SHA1

which provides only message integrity (without authentication!) all the
way to bleeding-edge:

    # openssl ciphers -v 'kECDHE+aECDSA+AESGCM+AES256'
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD

which given a suitably secure selection of curves provides PFS,
ECDSA authentication, and strong encryption with authenticated
message integrity.

Given the long discussion on [saag], I think we have rough consensus on
"opportunistic security" as an acceptable choice of name.

> encryption.  So I suggest it be deferred.

I'll do whatever it takes to emphasize that the definition is NOT
to be mistaken for just "encrypt when possible" (without authentication).
The term is intentionally *opportunistic security*, not just
mitigation of passive intercepts.

In particular, one important example of "opportunistic security"
is opportunistic DANE TLS in the DANE WG SMTP draft.  Here for
domains that publish DNSSEC "secure" MX records and TLSA RRs for
the associated MX hosts, the client authenticates the SMTP server
and the protocol is resistant to various MiTM/downgrade attacks.

And yet it is opportunistic, because DANE authentication applies
when possible, and otherwise the SMTP client employs legacy
opportunistic TLS, which may even transmit in cleartext when
the peer does not appear to support STARTTLS.

It is my hope that promoting "opportunistic security" not be
tantamount to promoting abandoning authentication.  Sure we
want to *at least* encrypt, when possible, but that is *not*
the maximal security we should aim for.  We should be looking
to deploy protocols that offer a range of capabilities, and
should deploy designs in which peers strive to eke out as
much security (umbrella term) as possible.

>    2.  The document says it is providing a definition, but it does not

Here I am open to improved language that sums up the design principles
characteristic of opportunistic security into a definition.  We
should be mindful of the fact that the term is an umbrella term,
and the "definition" cannot precisely define behaviour, rather
it needs to define a design approach.

>          unauthenticated encryption when authentication is not

Suggestions to the specific language that make the definition more
clear are definitely welcome.  I am not ready to adopt the above
text in preference to the current version.

>  It other words, it is confusing the thing with the context in which the

Protocols that employ opportunistic security may include fallback
to cleartext, where necessary for interoperability with existing
or unavoidably less capable systems.  If there are specific places
where this is unclear, I'd be more than happy to clarify.

> encryption is possible in a /session/ it might be permitted to fall back

Opportunistic security is an umbrella term for protocol designs
that strive to interoperate at the maximum available "security"
with a given peer.  Once we have some specific form of encryption,
or authentication, the adjective "opportunistic" is no longer
applicable.  "Opportunistic" is about the willingness to find a
mutually agreeable security mechanism, it is not the mechanism
itself once the choice is made.

Therefore, I am advocating essentially the opposite view.  Encryption
is just encryption, it may or may not be unauthenticated.
Opportunistic security is a flexible policy, which may leads to
encryption, possibly authenticated, or may lead to cleartext.
Neither cleartext, nor unauthenticated encryption, nor authenticated
encryption are "opportunistic".

> meant to be limited to server-side authentication.

No.  There are potential opportunities for opportunistic authentication
of clients also, exploring this question in the context of DANE is
part of the new DANE WG charter.

> That is, the

A recent discussion of the draft mentioned "strategic ambiguity",
I think it is relevant here.  We're not circumscribing the capabilities
of the peers or limiting the scope of security services that
opportunistic security can provide.

> meaning.  That meaning should be provided explicitly.

The intention is that "strong" means roughly comparable to the
protection provided by existing non-opportunistic designs, thus
generally resistant to most passive and active attacks.  Some
strategic ambiguity is also appropriate here.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Jul 2014 19:23:54 +0000

On Fri, Jul 11, 2014 at 01:46:18PM +0100, ianG wrote:

> In the below, I experiment with the term 'complete protection' rather
> than 'strong security'.
> 
> > The draft makes a stab at calling the alternate 'strong protection' but
> > does not go much further.
> 
>    Abstract.
> 
>    the established approach of delivering complete protection when
>    possible, and none if not possible, ...
>
> [...]

So is "complete protection" as proposed by "iang" a better term
for the historical alternative?  The plausible choices are the
current language "strong security", iang's "complete security", or
perhaps "comprehensive security" (which arguably avoids the maximality
of "complete" or "strong").

None of the above are established terminology, so a related question
is whether whatever term is used requires a brief detour to define
it?  My initial goal was to strive to avoid detours, and focus on
defining opportustinic security.  It was my hope that other terms
are either sufficiently clear from context, or that defining them
precisely is not essential to the task at hand.

Perhaps in this particular case a sentence or two in the introduction
would not be too much of a distraction, but if this does not
significantly aid the clarity of the definition of opportunistic
security at the bottom of section 2, maybe defining legacy practice
is best done in another draft?

More than anything else I want it to be clear that opportunistic
security is not limited to just unauthenticated encryption.  The
last paragraph of section 2 attempts to address that goal.  If that
paragraph is not sufficiently clear, I am open to suggestions of
how to make it more so.

I am inclined to adopt the suggestion of the Gen-ART review to
change "MUST/SHOULD" to "must/should" in the last two paragraphs
of section 2.  If anyone prefers the current language, please
speak up.

-- 
	Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Jul 2014 15:48:42 -0400

I prefer the current text.

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Jul 2014 08:26:04 -0700

On 7/25/2014 3:19 PM, Dave Crocker wrote:
> However the document is not yet ready for publication.
...
> discussed therefore should be "opportunistic encryption".

AFAICT the meaning includes integrity protection as well as 
authentication based on an identity attached to the connection, so it's 
more than just encryption.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 30 Jul 2014 15:08:19 +0000

On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote:

> Having re-read the responses I think the term that comes closest is
> "all-or-nothing".  But even that doesn't seem to capture all of it,
> because "all" isn't what they achieve, they are quite conscious of
> ignoring certain threats such as tracking or DOS.
> 
> Perhaps "high bar" security or "fixed bar" security?  The flaw with much
> work in the past is that the bar was set high, and those who failed to
> leap it where knocked back.  So they walked around.

I like "all or nothing", "all" here is sensibly read as "everything
implemented", not "everything possible".  Thus simply a binary choice.

However, in trying to work this into the text I am finding that it
becomes more verbose, and spends too much time on inessential
details.  Perhaps this is just failure to craft the right text on
my part, but I am having a hard time actually improving the text
overall, even though "all or nothing" is perhaps better than "strong".

There is a tension here between a quick informal description of existing
practice, that should be clear to most, with a clear focus on the new
model, and a more accurate/detailed description of past practice, that
might detract from the focus of the document.

Is anyone willing to take the time to carefully update the Introduction
to find the sweet spot between the current cursory nod to the past on
one extreme, and potentially an overly elaborute detour on the other?

I tried a couple of times, but have not yet succeeded.  Writers
block and shortage of cycles perhaps...

I think that if we change nothing, though the document could likely
be improved, that the improvements are inessential.  Perhaps we
can leave well enough alone?

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2014 11:54:21 -0400

Dave,
> has no technical meaning, other than as a reference to an "area" of
since we're trying to be precise, those are called "security services."
> that is so vague or misleading (or both.)
I believe most folks now agree that it's a marketing term, and thus suffers
from the shortcomings you note.
> discussed therefore should be "opportunistic encryption".
My doc, which pre-fdated this one, provides an extensive explanation
for why the term "opportunistic encryption" is not technically appropriate.
>         The topic of this draft needs to be changed to "opportunistic
preferably not.
>     2.  The document says it is providing a definition, but it does not
agreed, and I offered one a few weeks ago.
> topic.  The discussion is useful, but it is not a definition.
agreed.
> pages, it is a specification or a discussion.  It is not a definition.
I concur and agree that a real definition is needed.
> The phrasing "variable protection strength during a session" probably
agreed.
> the context of the defined term.  This needs to be resolved, and carefully.
I would say:
"OS strives to greatly broaden the use of encryption in IETF protocols,
to combat PM. To facilitate incremental deployment, OS operates in
a fashion that may result in a plaintext connection/session."

> encryption.  This needs to be clarified in the text.
Typically true for TLS; not true for IPsec, not true for SSH, ...
> meaning.  That meaning should be provided explicitly.
agreed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 30 Jul 2014 17:31:15 +0000

> a fashion that may result in a plaintext connection/session."

This is I think addressed by the "Encrypt by default" principle,
but perhaps the below change helps to get the point across:

diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security
index a708120..f957e25 100644
--- a/draft-dukhovni-opportunistic-security
+++ b/draft-dukhovni-opportunistic-security
@@ -128,7 +128,10 @@
      <t hangText="Encrypt by default:"> An opportunistic security
      protocol MUST interoperably achieve at least unauthenticated
      encryption between peer systems that don't explicitly disable this
-     capability.  Over time, as peer software is updated to support
+     capability.  To facilitate incremental deployment, opportunistic
+     security protocols may tolerate cleartext connections or sessions
+     with peers that don't support
+     encryption.  Over time, as peer software is updated to support
      opportunistic security, only legacy systems or a minority of
      systems where encryption is disabled should be communicating in
      cleartext.  Whenever possible, opportunistic security should employ

I am careful to avoid suggesting that there is a single protocol
called "opportunistic security", umbrella (marketing) term and all
that...  So I used the phrase "opportunistic security protocols",
which is already used elsewhere in the document.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 30 Jul 2014 17:38:08 +0000

On Wed, Jul 30, 2014 at 10:22:22AM -0700, Martin Thomson wrote:

> On 30 July 2014 08:54, Stephen Kent <[email-masked]> wrote:
> > I would say:
> That's a good description of OE, but wasn't the whole point of using
> OS as the term to cover other opportunistic mechanisms, like maybe
> opportunistic authentication (which I just invented, but I hope is
> self-explanatory).

Since opportunistic security subsumes opportunistic unauthenticated
encryption (where applicable), the proposed text is technically
sound.  What remains to determine is to what extent the point is
already covered, and the exact language or location in the document
to update.

Yes, opportunistic security also subsumes designs with "opportunistic
authentication", such as proposed in the DANE SMTP draft, which
specifies "opportunistic DANE TLS" for SMTP.  I hope that other OS
protocols will indeed find a way to do "opportunistic authentication"
whenever possible and not just be limited to unauthenticated
encryption.

OS is a "golf umbrella" term... :-)

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2014 16:15:47 -0400

Martin,
> opportunistic authentication (which I just invented, but I hope is
I don't think so.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 31 Jul 2014 04:15:37 +0000

> I don't think so.

I am not sure what the "I don't think so" refers to.  If it is a
response to the question of whether the term "OS" was chosen
specifically to be more open-ended, then it depends on whom you
ask.  On the one hand a key constraint was to avoid using "OE"
which was already taken, so one might narrowly say that this is
the reason for the choice.  On the other hand, as the person who
advocated most strongly for this choice I did in fact have in mind
a definition that is more open-ended than than mere encryption when
possible.

And that more open-ended view is a key feature of the resulting
draft.

-- 
	Viktor.

---

From: t.p. <[email-masked]>
Date: Thu, 31 Jul 2014 12:32:19 +0100

----- Original Message -----
From: "Viktor Dukhovni" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 30, 2014 4:08 P

> On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote:
<snip>
> block and shortage of cycles perhaps...

How about

" Opportunistic security encourages peers to employ as much security as
   possible, without falling back to unnecessarily weak options.  In
   particular, opportunistic security encourages unauthenticated
   encryption when authentication is not possible.

  Without key management at an Internet scale,
   authentication is often not
   possible.  When, as a result,  protocols only offer the options of
either strongly
   authenticated secure channels, or else no security, traffic commonly
gets
   no security.  Therefore, in order to make encryption more
   ubiquitous, authentication needs to be optional.  When strongly
   authenticated communication is not possible, unauthenticated
   encryption is preferable to clear text.

  Historically, Internet security protocols have prioritized strong
   protection, for peers capable and motivated to absorb the associated
   costs and this has lead to most traffic being unprotected.  The fact
that most traffic is then
   unprotected facilitates pervasive monitoring (PM
   [RFC7258])  by nation states, by making such practices cost-effective
(or, at least, not cost-
   prohibitive).  Such indiscriminate [widespread?] collection of
communications traffic
   would be substantially less attractive to nation states if security
protocols
   offered a range of protection levels, offering encrypted
   transmission to most, if not all, peers and offering stronger
   security when required by policy or by opportunistic negotiation.

   Encryption remains easy, key management is difficult.  Key management
   at Internet scale is an incompletely solved problem.  The PKIX
   ([RFC5280]) key management model introduces costs that not all peers
   are willing to bear and also cannot secure
   communications when either the reference identity of the peer is
obtained
   indirectly over an insecure channel or the communicating parties
   cannot agree on a [root?] certification authority (CA).  Thus DNSSEC
is
   not at this time sufficiently widely adopted to make DANE a viable
   alternative at scale, while trust on first use (TOFU) key management
   models (such as with saved SSH fingerprints and various certificate
   pinning approaches) fail to protect initial contact; and, also,
require user
   intervention when there is a failure of key continuity.
"

I think that the paragraph order is key! Currently it is deductive, fine
for academic texts, less so for RFC, hence my switch to inductive.

Tom Petch

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 10:22:22 -0700

---

From: Henry B Hotz <[email-masked]>
Date: Wed, 30 Jul 2014 19:08:25 -0700

>> opportunistic authentication (which I just invented, but I hope is

Perhaps not, but it sounds a bit too binary for my taste. Without proposing an alternative (sorry!) I'd want it clearer that there may be an increasing number of multiple interoperable modes and a session should use the "best" one that can be agreed on.

As others have pointed out "best" may be ill-defined and you might need to trade e.g. better authentication against better encryption. I'm perfectly happy to leave the value function undefined, and I think we should be able to make the general principle clear.

Personal email.  [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2014 15:39:32 -0400

Tom,

It's very difficult to write text that accurately conveys the intent, 
and is yet
is technically precise.

For example, you wrote:

"Without key management at an Internet scale, authentication is often 
not possible."

*ephemeral DH exchange is a type of key management, and it works at 
Internet scale.**So, what I think you meant to say, when paraphrasing 
Viktor (who made the same mistake in the I-D) **
**is something like*

"Authenticated key management at an Internet scale has yet to be achieved."

*later the text says: *

"Key management at Internet scale is an incompletely solved problem."

*again, missing the necessary qualifier "authenticated"**
**and later:*

The PKIX ([RFC5280]) key management model introduces costs that not all 
peers are willing to bear and also cannot secure communications when 
either the reference identity *(not defined in the I-D)*
of the peer is obtained indirectly over an insecure channel or the 
communicating parties cannot agree on a [root?] certification authority 
(CA).

*This statement is inaccurate. If peers share a common, trusted CA, they 
can validate one anothers**
**certs, whether that CA is a trust anchor ("root CA") in the Web PKI 
sense or not.**
**
**As you may surmise, I avoided reading Viktor's doc. I will do so now, 
and provide detailed**
**comments during IETF LC, to address these and other issues.*

Steve

---

From: t.p. <[email-masked]>
Date: Thu, 31 Jul 2014 21:24:33 +0100

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2014 8:39 PM

Steve

Thank you for the comments.  I did not say, but my intent was to make
Viktor's statements clearer, easier to comment on, so if he made a
mistake, then my intention was to make the same mistake!

So,yes, I would add a reference for reference identity, such as RFC6125,
and my [ ?] was intended to convey that I thought that this needed
changing, about CAs.

But on key management, I am not sure I agree with you.  Yes, ECDHE
is a part of key management, but I would not think it on its own as
being key management; or put differently, you either have key
management or you do not, so 'authenticated key management'
seems to me .. well, not real.  I look in vain for it in RFC2401
or RFC2828.

Tom Petch

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 31 Jul 2014 22:32:42 +0000

> seems to me .. well, not real.  I look in vain for it in RFC2401

One tends to distinguish between key management and key agreement.
I've not previously seen ephemeral key agreement described as key
management.  I don't think there is substantive ambiguity with
respect to the meaning of key management in the draft.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Aug 2014 01:30:06 +0200 (CEST)

Stephen Kent wrote:
> and yet is technically precise.

Full ACK.  :-)

> "Authenticated key management at an Internet scale has yet to be achieved."

I think it is in general a _bad_ idea to describe an ephemeral DH exchange
as some form of key management -- because it is *NOT* key management.

To me, the use of the word "management" implies _control_ over keys.

An _unauthenticated_ DH key exchange protocol is where both peers
give a f*** about control of keys, is a mathematical scheme where
both peers end up computing the same key.  But due to the _lack_ of
control (aka lack of management), neither party knows which other
party has that same DH key, whether it is the peer they believe to
be talking to, or whether it is a man-in-the-middle who makes them
believe that they talking to each other directly.
 
If the DH exchange is _authenticated_, then this is where "control"
comes into play, aka "management" of who is party to the keys and
party to the communication.

-Martin