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

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 16:34:44 +0100

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

---

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:
> _______________________________________________
> 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: 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.

What's the problem?  How has the process been circumvented, in its
letter or spirit?

Nico
--

---

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

> What's the problem?  How has the process been circumvented, in its

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: 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: Michael Richardson <[email-masked]>
Date: Tue, 08 Jul 2014 16:51:44 -0400

>  - The individual submission track exists in part for just this sort of

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: Nico Williams <[email-masked]>
Date: Tue, 8 Jul 2014 16:16:38 -0500

> again (with less friction).

Yep, right you are.

---

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

On Tue, Jul 8, 2014 at 1:51 PM, Michael Richardson <[email-masked]>
wrote:

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

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: ianG <[email-masked]>
Date: Thu, 10 Jul 2014 11:13:57 +0100

An anecdote.  Last night I was asked to describe opportunistic security.
 After thinking about it, I realised that first I had to describe the
alternate, as OS only makes full sense when contrasted.  So I did that.
 End of anecdote.

This immediately raised several issues in my mind:

    * What is the alternate?
    * What is its name?
    * Is there a document for this?
    * Shouldn't the present draft refer to it?

Looking at the draft, it says:

   time, ....

   Historically, Internet security protocols have prioritized strong
   protection for peers capable and motivated to absorb the associated
   costs.  Since strong protection is not universally applicable, while
   communications traffic was sometimes strongly secured, more typically
   it was not protected at all. ....

The draft makes a stab at calling the alternate 'strong protection' but
does not go much further.

So, maybe for my own curiosity, is there a name/doc/definition within
IETF for the alternate, perhaps briefly known as strong protection?

iang

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 11:40:20 +0100

> IETF for the alternate, perhaps briefly known as strong protection?

Others are better at this than me, but I guess the combination of RFCs
3365 (BCP61) and 4107 (BCP107), and the advice from RFC 3552 (BCP72).

But I think partly this also goes back to the late 1990's and earlier
when many designs started to mature - up to then it was entirely
reasonable to design for enterprise environments for most things and
so that's what we did, and in such environments mutual authentication
is a good goal still, even if doing that gets very complicated and
expensive for very large enterprises. So the OS story isn't really
a case of fixing something broken but more catching up with
requirements that changed. At least that's how I think about it.

S.

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Jul 2014 10:46:37 -0400

This raises an important question as to why "doing that gets very complicated and expensive".  It would make sense to document reasons for why this is so in an I-D by itself. I often wonder whether this is a self-inflicted wound caused by the security profession itself, has economical drivers, or would be caused by lax policies, for example.

In many groups, discussions on perceived or real complexity of security design elements keep coming up over and over again and this is unlikely to stop soon. To me, this seems a priority one item for saag to reflect upon.

Rene

==

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

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 10 Jul 2014 11:20:37 -0400

> does not go much further.

Disagree.  "strong protection" is something opportunistic security
strategies can provide when possible.  Using that term for the
alternate to opportunistic would be misleading.  The draft doesn't
present "strong" as the alternate, but if people misread the draft
in this way, perhaps the draft needs some tweaking?

The alternate to OS that the draft describes here, is falling back to
no security when whatever your protocol was trying to do (which may be
"strong") is not possible, without allowing for the case that
something less strong is possible.  OS is about providing "strong"
when it can be done, and something less when when it cannot.

The alternative to OS is falling back to less security than is
available because you couldn't get something better than is available.
  -- Cos

---

From: Nico Williams <[email-masked]>
Date: Thu, 10 Jul 2014 10:48:16 -0500

On Thu, Jul 10, 2014 at 10:20 AM, Ofer Inbar <[email-masked]> wrote:
> > [...]

+1.  Alternatives (plural) to OS:

 - make strong authentication with introducers scale (but we've failed so far)
 - no security

We don't need to define them where we define OS in order to define OS.
In particular we don't need to define "no security"/"insecure": every
one knows what that means :/

> available because you couldn't get something better than is available.

Right.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 10 Jul 2014 11:49:19 -0400

> when it can be done, and something less when when it cannot.

So perhaps the alternative is "all-or-nothing" security?

The two main alternatives to OS i've seen in practice are:

 0) strong protection if possible, connection failure otherwise, (e.g.
HTTPS attempts in most web browsers) or

 1) strong protection if possible, no protection at all (but no
connection failure) otherwise. (e.g. SMTP cleartext retry on STARTTLS
certificate validation failure)

both of these are a sort of "all or nothing" approach.

	--dkg

---

From: ianG <[email-masked]>
Date: Thu, 10 Jul 2014 17:44:14 +0100

> 3365 (BCP61) and 4107 (BCP107), and the advice from RFC 3552 (BCP72).

I looked through those, and I'd say they do not come close to providing
a framework that could be considered an alternate, although I sense
their frustration.  Here's what I had in mind, scratched out in a
morning.  I have one feedback which is "needs pictures".

*Model Security*

Abstract.  The classical or accepted approach to software security
systems is based on Models.  These models in aggregate create a strategy
of defence often called the Security Model, which addresses some threats
well, others less well.  The final selection of these threats and their
mitigations is based on the work of expressing a Business Model, a
Threat Model and a Risk Model.

*The Models in Security*

We start with a _Business Model_.  This gives grounding to that value we
are trying to protect, the players, the constraints, etc.

For example, the SSL system was designed to a business model of credit
card transactions over the Internet in the then-emerging field of
e-commerce.  The users were assumed to have no prior relationship with
the merchant, and the technology of communication was assumed to be WWW.

Then, we construct a _Threat Model_, being an enumeration of all the bad
things that can happen to the business.

Next, we construct a _Risk Model_, which develops the threats by
estimating their expected cost and likelihood, and adds potential
mitigations which carry their costs to employ.  With some calculation,
we develop an overall view of risk to the business that can be
prioritised according to best cost-benefit in applying different
mitigations.  We can then model different subsets of mitigations for
cost-benefit analysis.

Finally, we select a _Security Model_ by choosing a subset of threats
and mitigations from the above risk model exercise.  The mitigations are
proposed as the set to spend resources on, leaving the unmitigated
threats to be 'accepted' as costs of business.

*Strengths in Model Security*

The modelled approach represents a scientific approach.  It draws from
various disciplines to create a pathway by which the choice of
mitigations can be documented, debated, agreed and promulgated.

It is extremely flexible as it can cope with many broader security
scenarios;  as well as infosec, the model is widely used in physical
security and terrorism defence fields.

When well-documented, it lends itself to wide communication, fast
appreciation by newcomers and auditability.

*Weaknesses in the Model-based approach to Security*

Some of the models or steps can be skipped, skimmed or mishandled for
various reasons:  lack of understanding, appreciation or resources
(e.g., time).

The overall approach is very expensive.  It is not infrequent for
serious systems to require many man-years of work to create a fully
documented set of models.

A security model can become over-used.  In particular, it can be
misapplied to businesses that have different initial circumstances, and
in the extreme, the model can make security matters worse while
camouflaging the loss.

The complexity of the approach gives rise to a 'guild approach' to
security which is often seen as a barrier.  Especially, as real security
is faced by thinking attackers, their ability to migrate their tactics
can exceed the ability of model security to adjust (c.f. OODA loops).
Assumptions about likely attackers can become beliefs that are untested
or unreal.

The complexity of the models approach makes it vulnerable to being used
to prove the solution.  That is, a seller of a particular solution can
craft a suite of models that is designed to prove on paper the efficacy
of the solution, but is too complex to challenge.

---

From: Nico Williams <[email-masked]>
Date: Thu, 10 Jul 2014 12:23:40 -0500

On Thu, Jul 10, 2014 at 9:46 AM, Rene Struik <[email-masked]> wrote:
> This raises an important question as to why "doing that gets very

["that" == mutual authentication]

> complicated and expensive".  It would make sense to document reasons for why
> this is so in an I-D by itself. I often wonder whether this is a
> self-inflicted wound caused by the security profession itself, has
> economical drivers, or would be caused by lax policies, for example.
>
> In many groups, discussions on perceived or real complexity of security
> design elements keep coming up over and over again and this is unlikely to
> stop soon. To me, this seems a priority one item for saag to reflect upon.

I agree.  The subject of mutual authentication has come up many, many
times here (IETF security area, and IETF in general).

There's a lot to say about this subject.  I'll make a list later today.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 19:47:04 +0200

Rene,

correct me if I am wrong but I believe you are referring to discussions
that relate to the complexity of various security mechanisms on Internet
of Things devices.

I doubt that an abstract discussion will be the right response.

I believe that this story is similar to the case with TLS a few years
ago when the common (mis)believe was that TLS is prohibitively
expensive. Then, Google enabled it on all their services and worries
were suddenly gone.

Ciao
Hannes

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Jul 2014 10:51:10 -0700

> certificate validation failure)

TOFU is another option in this space, but where many of the strong
protection schemes fail to scale out in numbers, TOFU fails to provide
continuous protection, including the initial leap.

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Jul 2014 13:57:21 -0400

Hi Hannes:

Any I-D that would dis-spell myths would of course also have value. 
Right now, it is hard to point at a comprehensive source; hence, my 
suggestion.

BTW - I can imagine that you could  weigh-in on this with a contribution 
to this suggested effort on how "raw public keys" fit into this picture.

I never suggested an abstract discussion; those are your words.

Best regards, Rene

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 20:37:56 +0200

Hi Rene,

> I never suggested an abstract discussion; those are your words.

I was thinking about the most recent mail on the DICE mailing list and
the argument "requiring more capable devices slows
and limits market adoption" was brought up.

The issue is of course about the type of protocol/cryptography being
used for mutual authentication (instead of whether mutual authentication
should be supported or not).

Ciao
Hannes

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Jul 2014 14:55:09 -0400

Hi Hannes:

The question I raised was triggered by Stephen Farrell's suggestion that 
"doing that [mutual authentication] gets very complicated and 
expensive".  There seems to be more to that than just the cost of some 
software or hardware on a device (for otherwise, why would Stephen bring 
this up in the context of opportunistic encryption and "catching up with 
requirements that changes" (which I read as "mass surveillance") -- 
after all, the code size of the TLS stack does not seem to be dominated 
by crypto libraries).

Again, if I am wrong and it would be just the cost of some software or 
hardware on a device, that would be good to establish. If there is more 
to this, then we should list this and make sure we work towards 
addressing the complexities and expenses that were suggested.

Stephen, any thought on this? What did you mean?

Rene
[BTW - if my email was on DICE issues, I would have responded to the 
DICE WG. It was not, though]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Jul 2014 21:17:06 +0200

> So perhaps the alternative is "all-or-nothing" security?

I suggest we not think in such stark terms.  There are going to be
variants all around us.  Especially in the home where registration is a
challenge, but by no means impossible (I'd just call it ongoing work).

Eliot

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 10 Jul 2014 15:29:17 -0400

> challenge, but by no means impossible (I'd just call it ongoing work).

For the record, I didn't write that line :)

The way I put it was "the alternative to OS is falling back to less
security than is available because you couldn't get something better
than is available."

Maybe another way of looking at it is that the "alternate" is deciding
in advance on a specific set of parameters you'll do, without building
in flexibility to do something else when what you wanted in advance is
not achievable.  Either way, it's a continuum: "opportunistic" means
building in more flexibility with the goal of getting the best available.
Too little flexibility leading to the failure of "falling back to less
security than is available" = your approach is less opportunistic.  If
it fails in that way frequently, then it's insufficiently opportunistic
for the context it's deployed in, when looked at from the OS point of view.
If it rarely fails that way, then it's sufficiently opportunistic in context.
  -- Cos

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Jul 2014 23:28:26 +0000

> both of these are a sort of "all or nothing" approach.

Correct.  In particular OS is adaptive, peer by peer, to achieve
"best possible" (under the circumstances) protection with that peer.

The "all-or-nothing" alternatives are not adaptive, and leave a
lot of destinations unprotected.  I should Note that the mail
failure mode of HTTPS is HTTP, which it is my impression is still
more prevalent than HTTPS.

For many web sites users get to HTTPS after a redirect to HTTPS or
by clicking on a "secure-login" link.  So the practice of HTTPS is
often different from the presumed model.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jul 2014 11:06:52 +0100

Hi Rene,

> requirements that changes" (which I read as "mass surveillance") --

No I don't think pervasive monitoring (PM) is the main change at
all though it is something we need to better mitigate, and the OS
work is part of that for sure.

I think the size of the Internet has been the main change.

Some of our security (and other) technologies were designed
15 or so years back mostly considering enterprise networks with
say 10^6 or fewer things involved and where there were folks
whose day job was to mind every part of that network. A lot of
reasonable assumptions in that context no longer really apply.

For example, I think the ability to relatively easily set up
useful mutual (or even one-way) authentication to the point
where you hard-fail or go insecure when you don't get that
authentication is one of those assumptions.

So the OS work is not only about PM, but is also about making
security mechanisms easier to use, and more likely to be used.

Cheers,
S.

PS: I'll just note that we do not need to have consensus on
the "history" bits of the above which is just my impression of
what folks were mostly thinking about 15-20 years ago. So we
don't need to agree that I'm right or wrong as to what went on
then:-)

---

From: ianG <[email-masked]>
Date: Fri, 11 Jul 2014 13:21:32 +0100

On 10/07/2014 16:20 pm, Ofer Inbar wrote:
> alternate to opportunistic would be misleading.

FTR, I entirely agree, "strong" is the wrong term.

My notion of 'model security' as no more than a thought experiment on
what that alternate might be.

> The draft doesn't

Yep -- but *why is it acceptable to fall back to zero security* ?

AFAICS, the model said that there was a minimum level of security that
was needed.  Else stop.  Reject that business?

(Hence the term, model security.)

(I'm not trying to figure out a better understanding for it, just find a
label and approximate flavour that we can all agree on for it.)

iang

---

From: ianG <[email-masked]>
Date: Fri, 11 Jul 2014 13:46:18 +0100

On 10/07/2014 11:13 am, ianG wrote:
...

> This immediately raised several issues in my mind:

In the below, I experiment with the term 'complete protection' rather
than 'strong security'.

> does not go much further.

   Abstract.

   This memo defines the term "opportunistic security".  In contrast to
   the established approach of delivering complete protection when
   possible, and none if not possible, ...

   1. Intro.

   Historically, Internet security protocols have prioritized complete
   protection for peers capable and motivated to absorb the associated
   costs.  Complete protection has been defined within protocol as to
   require full mitigation of certain agreed threats, and to fail
   completely if such threats could not be fully mitigated.  For
   example, authentication.

   Such a complete protection is not universally applicable, and in
   many contexts there is an opportunity for substantial benefit from
   partial mitigation.  E.g., in order to mitigate pervasive monitoring,
   opportunistic encryption without authentication would be a big step
   forward.

   Further, the complexities of defining a complete security envelope
   that satisfied everyone often led to a race to the top.  This high
   standard put such pressure on the costs of implementation that the
   deployment of solutions fell down drastically.  When the choice was
   all-or-nothing, far too frequently users got nothing.

   This draft introduces "opportunistic security" as a better way to
   address the needs of Internet users and mass traffic, by deploying
   some protection more of the time.
...

Note.  I was really whiteboarding here for myself, and am only sending
this because of the strident response from Martin/Gen-Art.  Feel free to
ignore, but if there is to be a wholesale revision anyway, well... let's
get it right.

iang

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jul 2014 13:56:19 +0100

On 11/07/14 13:46, ianG wrote:
>  but if there is to be a wholesale revision anyway

Too early to say that. Martin commented and Viktor
responded and we'll see where that goes.

And in case not everyone knows, documents in IETF LC
get various directorate reviews (secdir, gen-art, etc.)
which are organised in different ways but all of them
ought be handled just like other LC comments sent by
anyone - just because its the foo-dir review doesn't
change that.

Cheers,
S.

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Jul 2014 09:49:00 -0400

Dear Stephen:

Thanks for your  note. Problem with your note is that it is very generic 
and not actionable at all.

It would be good if we could document the reasons for the real or 
perceived complexity and cost. Only if we know what the problems are, 
can we solve them...

Some more comments inline.

Rene

> reasonable assumptions in that context no longer really apply.
RS>>
It would help to specify and enumerate the reasonable assumptions at 
that time and why those "no longer really apply".

BTW - it seems you are suggesting that now mutual authentication has to 
deal with more than 10^6 things involved and that that makes a 
difference. If so, it would be good to clarify whether this is in one 
network or administrative domain or just an aggregate of all objects out 
there (and articulating whether one really wants to connect two random 
objects in the world). Why would the 10^6 threshold make a difference. 
What problems creep up. Etc, etc.? Is the problem in admin-heavy 
architectures, witness "where there were folks whose days job was to 
mind every part of the network", or something else? For me, it is hard 
to tell.
<<RS
> authentication is one of those assumptions.
RS>>
Again, it would help to describe why this assumption held up, but now 
apparently (your argument) does not any more. Some supporting evidence, 
including classification of where the source of the problems is helps 
(technical from security perspective, security architectural, 
economical, self-inflicted, due to spokes [or spooks?] in the wheel) 
helps here, since would provide a problem statement.
<<RS

So the OS work is not only about PM, but is also about making security 
mechanisms easier to use, and more likely to be used. Cheers, S. PS: 
I'll just note that we do not need to have consensus on the "history" 
bits of the above which is just my impression of what folks were mostly 
thinking about 15-20 years ago. So we don't need to agree that I'm right 
or wrong as to what went on then:-)

RS>>
If OS has more global revolutionary aspirations, it would be good to 
describe this somewhere. I got the impression that opportunistic 
encryption was more about administrator-less security. If wrong and this 
is about raising the security bar while at the same time improving ease 
of use and ease of deployability, that would be good to codify. To my 
knowledge, the ease of use argument has not been used. Or, are you 
referring to autonomic networking activities? If the answer is "yes, we 
are going to do all", that is okay, but still requires a current state, 
identification of deltas, etc. Now, it is hard to guess what problem you 
are trying to bring up, since I mostly see some fuzzy feel-good factors, 
which are not actionable and do not provide a problem statement.
<<RS

---

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

---

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: 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: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: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jul 2014 15:43:09 +0100

Hiya,

> and not actionable at all.

Hmm... That's probably ok since it wasn't intended to be
actionable at all. I was responding to a comment and simply
gave my impression of a bit of the background. Its not
really that important. And its defo. not something on which
we need to (dis)agree in an IETF context.

> perceived complexity and cost. 

Sure. If someone did want to try document how and why all our
current set of standardised security mechanisms came about,
or try to characterise their strengths and weaknesses, that
would be interesting. But I suspect it'd be a lot of
controversial work for little benefit. And I don't plan on
trying to do that fwiw:-)

> Only if we know what the problems are,
> can we solve them...

No. I do not agree that we need an exhaustive list of problems,
nor a characterisation of all that's bad about current security
protocols, before we can make progress. I definitely do not
agree that we need a description of why such defects may have
come into existence, before we can make progress.

I think its much easier than that.

We think that e.g. SMTP/TLS between MTAs was used maybe about
20% of the time up to a year or so ago (from offlist mail I've
gotten, dunno if there's good published info). FB published
stats with that at about 60% recently, with maybe half of
that being OS. That by itself is good enough for me, even
though I think the argument for OS being useful could be
made without that evidence. (Mind you, I'm biased as I was
already convinced myself beforehand:-)

By "good enough" I mean its good enough to convince me that
OS has potential benefit, and hence that defining that to
make it easier to use is a good idea. And via the IETF LC,
we'll see if Viktor's draft that aims to do that is something
on which the IETF do, or do not, have consensus. Its all
pretty simple really.

Now, when it comes to discussion of how and whether to use
OS in some specific context (e.g. HTTP) then that should be
discussed wherever the relevant protocol is being developed
(httpbis in that case) and not here (which has been done in
the HTTP case too). And as I commented to Eliot in the LC
thread, its pretty early days in some respects so we're not
at a stage where we have a worked out consensus recommending
when protocols should or should not use OS. For now, we're
just defining OS so that it can more easily be used without
re-running the basic arguments over and over should folks
want to use this appraoch. (Again, as has happened in httpbis,
though if they had had this draft as an RFC, that'd have
saved them some time, effort and even a little bit of angst.)

> Some more comments inline.

I didn't do a blow-by-blow response to those, as I think the
above covers it.

Cheers,
S.

PS: Global revolution? Really? :-)

---

From: ianG <[email-masked]>
Date: Sat, 12 Jul 2014 12:38:49 +0100

> that time and why those "no longer really apply".

The clue I see is 'enterprise'.  Many people working in the 1990s were
employed by corporations (people needed to eat, right?).  The
corporations could afford the costs of authentication systems, and some
of those corporations were the costs of the authentication systems.
There was a bias towards authentication as commercially viable business
model.

Fast forward to now, and the cost of these authentication systems has
delivered a rather mixed result.  Yes, it worked in the direct case, but
there are many side-effects, and poor deployment.  A lot of the failures
trace back to the cost-of-authentication assumptions.

So, the OS strategy has it that we make authentication free.  By not
doing it, if necessary, and by making it available if we can.

...
> apparently (your argument) does not any more.

Look at HTTPS.  A huge part of the problem with phishing is that the web
isn't fully encrypted and authenticated.  When it was first envisaged,
it was hoped that everything would be covered for any retail site, and
therefore we could lean more heavily on certificates.

But when first deployed (1995?) the cost of encryption was too high, so
the retail websites split into credit card accepting on HTTPS, and the
rest on HTTP.  Fast forward to 2003 and the expected phishing attacks
simply launched copy sites in HTTP.  Nobody could tell the difference,
and the browsers couldn't help.

The real solution here is to get everything onto HTTPS, the same system.
 Once that is done, browsers can more heavily concentrate on the
reliance of the name, because it is more often there.

Assumptions that have changed:  cost of encryption.  Need for full
authentication.  Discovery of pervasive monitoring.  Need to serve
business foremost.

> of use and ease of deployability, that would be good to codify.

Yes, it's both, causally.  To improve security, we want to make it
administrator-free.

iang

---

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

>    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: ianG <[email-masked]>
Date: Mon, 28 Jul 2014 23:04:50 +0100

On 27/07/2014 20:23 pm, Viktor Dukhovni wrote:
> for the historical alternative?

Yet, OS can also provide the same complete envelope in certain cases (as
others have pointed out).

> The plausible choices are the

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.

Instead we want to change the paradigm.  We want to lift the bar to the
height that the jumper can leap, not filter the jumper by the height of
the bar, set arbitrarily high.

> precisely is not essential to the task at hand.

It's a tough call.  In order to better define terms, we are taken down
the rabbit hole of "what's the alternative..."  Gen-ART more or less
suggests it.

> security is not limited to just unauthenticated encryption.

( Just to digress on that.  The requirement of unauthenticated
encryption came from somewhere.  It wasn't conjured out of thin air,
there exists a process that concludes "and we must authenticate."  It
was that idea I was trying to capture with "model security" [0]. )

...

Combining words above and the Gen-ART review into the draft:

   Abstract

   This memo defines the term "opportunistic security".  In contrast to
   the established *high bar approach of strongly protecting 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.

   ....
   1. Introduction

   Historically, Internet security protocols have set a high bar
   for security of communicating peers, often based on a shared
   understanding of what threats were important [1].  Setting a
   high bar created an insistence on failure for those peers
   which were not capable and motivated to absorb the
   associated costs.  This insistence on failure elicited
   many responses from users to work around the problem
   (accept bad certificates, suppress certificate checking,
   use totally unsecured means, etc), resulted in many
   peers abandoning security altogether, and ultimately
   facilitated nation-state pervasive monitoring ([RFC7258]).

   In contrast to the
   high bar approach, an OS implementation can accept unvalidated
   credentials, weak credentials or even no credentials and still
   deliver a secured communication that delivers resilience
   against a passive attacker.

   Protecting most traffic against passive attacks would render
   nation state pervasive monitoring non-cost-effective.
   Indiscriminate collection of communications traffic
   would be substantially less attractive if security protocols were
   designed to operate at a range of protection levels with encrypted
   transmission accessible to most if not all peers, and stronger
   security still available where required by policy or
   opportunistically negotiated.
   ....

Just some words hacked in to the existing text, I'm sure others can do
better.

iang

[0] http://www.ietf.org/mail-archive/web/saag/current/msg05194.html

[1] one of the RFCs that Steve Farrell pointed to described the ITM or
Internet Threat Model, being a shared understanding that included the
requirement to authenticate.  Whether it is worth referencing or even
commenting on the notion of a shared threat model, I don't know.

---

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

> 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:43:50 -0400

The phrase "complete protection" is misleading, and, as Viktor, notes, not
established terminoogy. Some protocols (e.g., ESP) offer optional TFS 
measures,
most don't. So a protocol that doesn't offer any TFS is incomplete, even 
though
it may require mutual authentication.

Steve

---

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

Dave,
> On 7/8/2014 11:09 AM, The IESG wrote:
> 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.
since we're trying to be precise, those are called "security services."
>         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.)
I believe most folks now agree that it's a marketing term, and thus suffers
from the shortcomings you note.
>
>         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".
My doc, which pre-fdated this one, provides an extensive explanation
for why the term "opportunistic encryption" is not technically appropriate.
>         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".
preferably not.
>     2.  The document says it is providing a definition, but it does not
> do that.  It needs to.
agreed, and I offered one a few weeks ago.
>         What it does do is to provide an extended discussion of the
> topic.  The discussion is useful, but it is not a definition.
agreed.
>         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.
I concur and agree that a real definition is needed.
>        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...
agreed.
>     3.  The draft variously permits or prohibits use of cleartext within
> 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."

>   ...
>
>
>     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.
Typically true for TLS; not true for IPsec, not true for SSH, ...
>     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.
agreed.

---

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

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

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).

---

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

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

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: 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: 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: ianG <[email-masked]>
Date: Thu, 31 Jul 2014 09:38:41 +0100

> implemented", not "everything possible".  Thus simply a binary choice.

How about "minimum standard" ?

That is, the previous design approach set a minimum standard, below
which communication was rejected.

"Minimum standard" also has the benefits of being a widely established
term, and less emotionally charged than others.

> might detract from the focus of the document.

Yes, noted, definitely so.  Taking "minimum standard" for a road test:

   Introduction

-  Historically, Internet security protocols have prioritized strong
-  protection for peers capable and motivated to absorb the associated
-  costs.  Since strong protection is not universally applicable, while
-  communications traffic was sometimes strongly secured, more typically
-  it was not protected at all.

+  Historically, Internet security protocols have set a minimum
+  standard of strong protection for peers capable and motivated
+  to absorb the associated costs.
+  While some communications traffic met the minimum standard and
+  was strongly protected, more typically the standard was not
+  met and traffic was not protected at all.

   The fact that most traffic is
   unprotected facilitates nation-state pervasive monitoring (PM
   [RFC7258]) by making it cost-effective (or at least not cost-
   prohibitive).  Indiscriminate collection of communications traffic
   would be substantially less attractive if security protocols were
   designed to operate at a range of protection levels with encrypted
   transmission accessible to most if not all peers, and stronger
   security still available where required by policy or
   opportunistically negotiated.

> block and shortage of cycles perhaps...

I have also tried, without success.

> can leave well enough alone?

(The only reason I tinker here is because I saw the Art-Gen critique.
It makes a fair point that the definition is not as satisfying as hoped
for.  I guess that doesn't matter if the draft can be pushed through
that political process.)

iang

---

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: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2014 11:43:39 -0400

Henry,

> ...
> 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.
Perhaps my very brief response was too terse.

My point is that the motivation for the doc that I wrote, and the 
subsequent doc that
Viktor has written, is encouraging development of protocols that remove 
barriers to
widespread use of encryption, as an anti-PM measure. If authentication, 
integrity, or any
other service is provided, it's gravy. Thus I think it's a distraction 
to focus on these
other security services, when confidentiality is the primary driver for 
this work.
> 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.
I'm not in complete agreement with Viktor on this point (i.e., doing the 
best we can wrt
a broad set of security services). As I said above, lets' not confuse 
the message we're
trying to send to a very broad audience.

Steve

---

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

On Thu, Jul 31, 2014 at 11:43:39AM -0400, Stephen Kent wrote:

> My point is that the motivation for the doc that I wrote, and the subsequent
> doc that Viktor has written, is encouraging development of protocols that
> remove barriers to widespread use of encryption, as an anti-PM measure.
> If authentication, integrity, or any other service is provided, it's gravy.
> Thus I think it's a distraction to focus on these other security services,
> when confidentiality is the primary driver for this work.

I agree that we want to promote widespread use of encryption.  I don't
agree that leaving it at that is the right long-term objective.  We want
*at least* counter-measures to pervasive monitoring, but that's just a
beginning.  That said, I believe the draft under discussion is careful
to not get bogged down in detailed discussion of what additional security
might entail.  Rather it is careful to leave the door open to more security,
and encourages protocol designers to consider stronger options.

> best we can wrt a broad set of security services). As I said above, lets'
> not confuse the message we're trying to send to a very broad audience.

Well the message is don't resort cleartext just because you've
failed to reach some fixed high bar, find the "strongest" interoperable
security level, which may often be unauthenticated encryption, but
ideally is more than that.  So yes we disagree on the subleties of
the emphasis.  I want to promote widespread encryption, without
limiting the resulting security, by explicitly allowing for and
encouraging additional security services where applicable between
suitably capable peers.  The key different from the current fixed
high bar, is that now the bar is set individually for each peer.

-- 
	Viktor.