Subject: [saag] opportunistic security again

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Jul 2014 01:40:31 +0100

Hi all,

A while back Viktor posted a mail with a short chunk of
definitional text that seemed to be positively received
on this list. [1]

At my request, he's now posted that as an I-D [2] and
I'd like to get your thoughts as to whether we should
proceed with that and your comments on its content. When
this is baked then I plan to do an IETF LC for it. In
an ideal world I could start that before Toronto so
please comment in the next week if at all possible.

In case you're wondering, yes this does overlap with
Steve Kent's longer draft [3] that also has good history
and analysis of the issues. I'm chatting with Steve to
see how he suggests to proceed with a de-overlapped (is that
a word?;-) version of his text as well. I think that may
also be of use, though I'd like to first have the definitional
one [2] out the door if that's what seems to represent
rough consensus.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg05020.html
[2] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security
[3] https://tools.ietf.org/html/draft-kent-opportunistic-security

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Jul 2014 17:51:58 -0700

Hi, Stephen (et al.),

> one [2] out the door if that's what seems to represent

I think that the Dukhovni draft is a more useful starting point, but my 
concern is that - despite the abstract - the one term that is not 
defined is "opportunistic security" other than "providing some 
protection some of the time" -- which isn't horrible, but isn't explicit 
either.

The closest it comes is the indirect description of properties in Section 2:
	- supports full fallback if needed
	- uses the strongest security possible

The doc would benefit from including an explicit definition, e.g., in a 
preface of the properties in Section 2 or as a conclusion to their 
discussion.

Joe

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Jul 2014 00:59:18 +0000

On Tue, Jul 01, 2014 at 05:51:58PM -0700, Joe Touch wrote:

> concern is that - despite the abstract - the one term that is not defined is
> "opportunistic security" other than "providing some protection some of the
> time" -- which isn't horrible, but isn't explicit either.
> 

Right, the intention was to define opportunistic security as a design
which meets the criteria in section 2.

> preface of the properties in Section 2 or as a conclusion to their

This is I think a fair point.  Anyone want to suggest text (and/or
be a coauthor)?  I am on vacation, so cycles are limited.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Jul 2014 05:13:29 +0000

> be a coauthor)?  I am on vacation, so cycles are limited.

OK, here's a proposed defintional summary for the end of section 2.

diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security
index 8af06b9..39a305b 100644
--- a/draft-dukhovni-opportunistic-security
+++ b/draft-dukhovni-opportunistic-security
@@ -144,6 +144,18 @@
     </list>
    </t>
 
+   <t>
+     In summary, opportunistic security is an umbrella term describing
+     adaptive communications security protocols that emphasize
+     ubiquity over unconditional strong security.  The actual
+     protection provided by opportunistic security depends on the
+     capabilities of the communicating peers; opportunistic security
+     strives to at least encrypt network traffic without authentication,
+     while allowing fallback to cleartext with legacy peers, but
+     provides stronger security when possible on a peer-by-peer
+     basis.
+   </t>
+
   </section>
 
   <section title="Terminology" anchor="sec_terminology">

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Wed, 02 Jul 2014 08:34:45 +0100

> preface of the properties in Section 2 or as a conclusion to their

2c:

Opportunistic cryptography provides the strongest protection possible
within the constraints that (a) the caller has decided to go ahead and
communicate, and (b) only local or limited information, including none,
is available to authenticate.

In contrast, other forms assume the capability to stop & deny
communication, and require that certain authentication metrics be
available before proceeding.

iang

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 10:08:39 -0400

How about:

"Opportunistic security" is an umbrella term that encompasses protocol 
(and infrastructure?) mechanisms that remove barriers to the widespread 
use of encryption in the Internet. Protocols that exhibit opportunistic 
security MUST attempt to effect encryption of traffic, but SHALL fall 
back to plaintext transmission if a peer does not appear to support the 
required functionality. Opportunistic security protocols MAY provide one 
or two-way authentication, but an inability to provide authentication 
MUST NOT cause encryption to be effected if that security service was 
successfully enabled.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Jul 2014 07:23:14 -0700

I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that as someone who could not do a better job of writing a less opinionated version of the history. The history here is contentious and, I believe, not at all helpful in us getting community agreement on something with which we can move forwards.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Jul 2014 15:28:50 +0100

On 02/07/14 15:23, Paul Hoffman wrote:
> As for incorporating Steve's history: 

That was not the plan. I'm chatting with Steve about
him taking out the bits that overlap with Viktor's
definition-draft and to then separately progress the
history and analysis bits as appropriate in draft-kent.
I think while some of that may be controversial,
it could be done and could be useful. But no need to
get into that now, Steve has said it'll be after
Toronto before he has time to do those edits so we
can deal with it later.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Jul 2014 15:45:12 +0100

<no-hats>

I also think progressing Viktor's draft is a good
plan.

I think I prefer Steve's text below over Viktor's
from last night.

Other comments/nits on Viktor's -00:

1. s/draft-farrell-perpass-attack/rfc7258/ or BCP188
according to taste.

2. If using any 2119 terms, (which you currently do
once I think) then I guess you need a ref to 2119.
I suspect that this draft could get by without any
2119 terms though, so s/MUST/needs to/ in the 2nd
last para of section 2 (and if folks agree with
non-use of 2119 then equivalent changes would be
needed in Steve's definition below)

3. last para of section 2: wouldn't it be good to
say here that applications that do have a user
interface ought not make the use or non-use or
status of opportunistic security visible to the
user as a default, ("no lock icon!") but that
logging what's happened or allowing an advanced
user to drill down to see what's what can be ok
and useful? Or something like that?

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Jul 2014 10:45:10 -0400

➢ “Opportunistic security” is an umbrella term that encompasses protocol (and infrastructure?) mecha….

I like this paragraph!

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Jul 2014 10:54:45 -0400

> (and infrastructure?) mecha….

+1, I think I do prefer this definition as well, I'm just not sure on the
infrastructure part.  We all know it's easier to attack infrastructure, so
it's really important to protect it.  My question here is to figure out if
we think infrastructure is included in the goals for opportunistic security
or is that something else? If it is something else, do we need more work on
this as it seems to be forgotten quite a bit (maybe that is not in this
draft, but in another related to the sysadmin attacks where they were
targeted to gain access to infrastructure to monitor data, etc.).

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 11:11:14 -0400

Stephen Kent <[email-masked]> wrote:
    > ?Opportunistic security? is an umbrella term that encompasses protocol (and
    > infrastructure?) mechanisms that remove barriers to the widespread use of
    > encryption in the Internet. Protocols that exhibit opportunistic security MUST
    > attempt to effect encryption of traffic, but SHALL fall back to plaintext
    > transmission if a peer does not appear to support the required functionality.
    > Opportunistic security protocols MAY provide one or two-way authentication, but
    > an inability to provide authentication MUST NOT cause encryption to be effected
    > if that security service was successfully enabled.

I like this text better, and I like pointing out that the authentication can
be {0,1,2} end points.

Is it worth also saying:
   "While opportunistic security protocols MAY authenticate end points, the
   underlying trust of the end points MUST NOT be enhanced by this activity"

(and I'm willing to change "MUST NOT" to "SHOULD NOT")

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 11:13:33 -0400

> and useful? Or something like that?

Yes, that's what I was trying to get to. (keeping with the 2119 terms, as I'm
agnostic about your first point)

Opportunistic security protocols SHOULD audit their activity for diagnostic
purposes only, but MUST NOT change the trust model presented to the user
and/or upper protocol layers.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 11:15:35 -0400

> Toronto before he has time to do those edits so we

Good plan.
I think that it is useful that we have the history of how we got here.
I'm interested (over beer) in hearing about the controversial parts.
I'm mostly interested in documented that there was controversy.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Jul 2014 11:15:58 -0400

> (and I'm willing to change "MUST NOT" to "SHOULD NOT")

How about "is not"?  Underlying trust of the end points is separate from
any security offered by the protocol connecting those end points.  I'm not
sure MUST or SHOULD apply here, it's just separate (IMO).

Thanks.

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Wed, 02 Jul 2014 12:23:54 -0400

> I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that…

Agreed.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 02 Jul 2014 12:25:42 -0400

>    underlying trust of the end points MUST NOT be enhanced by this activity"

I think "underlying trust" is a term that's likely to sow more confusion
than it resolves.  I think you're referring to one peer's confidence
about the identity of the other peer, or confidence in the
confidentiality or integrity properties of the channel; all of these are
substantially different from how much one peer "trusts" the other.

I'm also not convinced that we want anyone employing opportunistic
security to actively *prohibit* user indicators in cases where strong
authentication is actually used.

That is: the use of opportunistic security without strong authentication
MUST NOT indicate to the user any level of confidence in the remote
peer's identity or in the security of the traffic by default.  But
strong authentication layered securely on top of an
opportunistically-acquired channel shouldn't preclude an indication to
the user.

As an example, most OTR chat clients (OTR is one of the most widespread
OS implementations) show that you're using OTR, but that the remote peer
is unauthenticated.  once a strong authentication step is done, the UI
indicates "authenticated".  MUST NOT language seems like it could be
read to prohibit this change.

	--dkg

---

From: Paul Wouters <[email-masked]>
Date: Wed, 02 Jul 2014 12:27:26 -0400

On 07/02/2014 10:08 AM, Stephen Kent wrote:
> How about:
> 
> "Opportunistic security" is an umbrella term that encompasses protocol (and infrastructure?) mechanisms that remove barriers to the widespread use of encryption
> in the Internet. Protocols that exhibit opportunistic security MUST attempt to effect encryption of traffic, but SHALL fall back to plaintext transmission if a
> peer does not appear to support the required functionality.

No this is wrong. If someone publishes a DANE or IPSECKEY record, and a client can validate that using DNSSEC, it MUST NOT fallback to plaintext.

(although some of this depends on the definition of "Opportunistic security")

 Opportunistic security protocols MAY provide one or two-way authentication,

or zero-way against only passive attacks?

 but an inability to
> provide authentication MUST NOT cause encryption to be effected if that security service was successfully enabled.

I don't understand this? On auth failure, remove the encryption? What would be gained by that?

Paul

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Jul 2014 12:43:59 -0400

>>>>> "SK" == Stephen Kent <[email-masked]> writes:

SK> "Opportunistic security" is an umbrella term that encompasses
SK> protocol (and infrastructure?) mechanisms that remove barriers to
SK> the widespread use of encryption in the Internet. Protocols that
SK> exhibit opportunistic security MUST attempt to effect encryption of
SK> traffic, but SHALL fall back to plaintext transmission if a peer
SK> does not appear to support the required functionality. Opportunistic
SK> security protocols MAY provide one or two-way authentication, but an
SK> inability to provide authentication MUST NOT cause encryption to be
SK> effected if that security service was successfully enabled.

I like that, too.

But is "effected" the intended word in the last sentence?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 13:04:47 -0400

Paul,
> No this is wrong. If someone publishes a DANE or IPSECKEY record, and a client can validate that using DNSSEC, it MUST NOT fallback to plaintext.
Please identify the specific phrase you believe is in error. My intent 
was to say that if a peer
does not support OS ("the required functionality", then the initiator of 
a session falls back to plaintext.
> or zero-way against only passive attacks?
One could add that OS does not implicitly offer any authentication, but 
that it MAY (as noted
in my text) provide one or two-way auth.

"zero-way" is not a term I've seen before. care to elaborate?
> I don't understand this? On auth failure, remove the encryption? What would be gained by that?
Sorry about the typo. I meant "affected."

Steve

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 10:10:45 -0700

I like this definition better than Steve's because it focuses on 
adaptability, which AFAICT is the key feature. I don't see the key 
feature being any single approach, including TOFU or unauthenticated 
encryption.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 10:13:12 -0700

FWIW, if we do prefer this text overall, I suggest the following changes:

On 7/2/2014 7:08 AM, Stephen Kent wrote:
> How about:
>
> “Opportunistic security” is an umbrella term that encompasses

insert "adaptive"

> protocol

IMO, if you use MUST in the first part, use MUST in the second (same 
meaning as SHALL as per RFC 2119, but less confusing to use a single term)

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 13:13:48 -0400

DKG,
> than it resolves.
I agree.
> I think you're referring to one peer's confidence
yes.
> authentication is actually used.
This is a tricky area. If OS yields the same level of authentication
as an extant security protocol, it's hard to argue that one ought not
provide the same security UI indication. But, if there is some difference
between an OS version of TLS and the current version that presents the lock
icon, then presenting that icon might create confusion.
> opportunistically-acquired channel shouldn't preclude an indication to
Oh, this is your concern. I didn't get that from the prior paragraph.
This is may be hard to do, depending on the context. If an OS-based
encrypted channel is established using protocol A, and authentication
is effected via protocol B (running over A) then one would not expect
a security UI indication for A to later be displayed, right?  If B has
its own security UI, then I would expect it to display the session status
based on what it did, as a client of A.
> read to prohibit this change.
This is an easy example, and in this case I concur.

Steve

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 10:14:21 -0700

+1

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 10:14:00 -0700

> But is "effected" the intended word in the last sentence?

Seems to me too like it should be "affected".

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 13:23:58 -0400

> I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that…
In writing my I-D I contacted several folks to get their input for the 
sections that describe
specific security protocols. Michael Richardson, Tero Kivinen, Russ 
Housley, Sean Turner,
Richard Barnes, Eric Rescorla, and Jon Peterson provided helpful 
feedback. I used their comments
to revise the text for the protocol sections. I contacted Paul, who said 
he didn't like the
definitions I selected, especially ones from RFC 4949, and he refused to 
provide any feedback
on the sections I sent to him. I assume this is Paul's definition of 
"highly opinionated and
therefore harmful."

Oh well, ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 13:29:12 -0400

Joe,
> feature being any single approach, including TOFU or unauthenticated 
Then you'll need to define what "adaptability" means. Many protocols 
already negotiate
algs, and some will negotiate NULL encryption, so the ability to "adapt" 
in this context
may not be so easy to define in a broadly agreed-upon fashion.

I do agree that no single feature of the sort you cite above is central 
to the notion
of "opportunistic." They are examples of mechanisms, and this doc should 
be able to define
the concept separate from examples of mechanisms.

Steve

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 10:51:49 -0700

> may not be so easy to define in a broadly agreed-upon fashion.

Certainly.

Agreed.

How's this? (admittedly a bit terse, but it might be a starting point):

OS is the combination of a protocol mechanisms and infrastructure 
approaches that determines and applies the best security possible for 
each given use rather than requiring any specific protection as a 
prerequisite.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 14:01:42 -0400

Joe,
> each given use rather than requiring any specific protection as a 
The refernce to "best" is worrisome. It's probably the best that can be 
achieved at the time of
session creation. if there was an active attack at that time, the "best" 
may change the next time
there is an attempt. Also, the sentence vaguely implies a fallback to 
plaintext, which may not be
obvious to many readers. The allusion to "specific protection" is true, 
but maybe too terse.
There is the IPsec notion of specified protection on a per-peer, 
bi-lateral basis, the TLS notion
of specified protection based on use of an HTTPS URL, etc. There's a lot 
of variance associated
with the phrase "specific protection" and that phrase has not been used 
widely, I believe.

Trying to be too terse can sacrifice clarity.

Steve

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 02 Jul 2014 14:10:21 -0400

On 07/02/2014 01:13 PM, Stephen Kent wrote:
> This is may be hard to do, depending on the context.

Yes, good UI/UX for security tools is hard to do.

> If an OS-based

Most users don't see the protocols A and B as distinct.  Probably, most
users don't even know that they're using protocols A and B at all.

The security indicators exposed to the users are usually within a
context of the particular application or utility that they're using.
That is, from their perspective, they're not using HTTP over TLS (over
TCP as resolved via DNS over UDP (with DNSSEC extensions, etc…)).
They're "surfing the web".

The application has (or should have) knowledge of all of the protocols
used, and should be able to make the determination about what
authenticity and security indicators to present to the user based on the
aggregate information.

	--dkg

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 11:27:58 -0700

On 7/2/2014 11:01 AM, Stephen Kent wrote:
> session creation.

Agreed; there's also a problem with the lack of a total ordering on the 
value of various aspects of security, so there may just be "different" 
features that are available in various constellations.

> if there was an active attack at that time, the "best"
> may change the next time
> obvious to many readers.

Agreed; I had that as an additional sentence that I omitted.

> The allusion to "specific protection" is true,
> but maybe too terse.

Granted. Here's take 2 (or 3,4, or 5, depending on your count origin). 
The first sentence is an attempt at a single-sentence definition (I 
always think that's better, when possible). The rest explains the 
motivation and makes it clear what we're focusing on - and, in a sense, 
what's 'opportunistic' about it without referring to any specific 
mechanism...

----

OS is the combination of protocol mechanisms and infrastructure that 
applies the strongest security possible (including "none") to a given 
use at the time invoked while still supporting communication. 
Communication security systems have traditionally focused on ensuring 
some set of particular protections, even if those guarantees prohibit 
communication in some cases. OS establishes communication as the sole 
fixed requirement; all other aspects of protection are optimized to 
increase security, but never at the expense of allowing communication to 
proceed.

---

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Jul 2014 16:44:42 -0400

>>>>> "IG" == ianG  <[email-masked]> writes:

ig> Opportunistic cryptography provides the strongest protection
ig> possible within the constraints that (a) the caller has decided to
ig> go ahead and communicate, and (b) only local or limited information,
ig> including none, is available to authenticate.

ig> In contrast, other forms assume the capability to stop & deny
ig> communication, and require that certain authentication metrics be
ig> available before proceeding.

That also looks convincing, except that many consider oe to include
cases where some participants are able to use one or more out-of-band
methods not only to authenticate themselves but also to insist on
authenticated-encrypt-or-block-until-it-works schematics.

Such as the case where tlsa records are used, but connections still are
accepted from legacy peers.

Unless of course that falls under (a).  If so, perhaps (a) requires a
bit more verbiage explaining that some callers may use more data than
others to decide whether to go ahead and communicate?

-JimC

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Jul 2014 17:16:03 -0400

JC> That also looks convincing,

Odd.  I meant to type compelling.

-JimC

---

From: Ronald del Rosario <[email-masked]>
Date: Wed, 2 Jul 2014 22:11:56 +0000

"Yes, good UI/UX for security tools is hard to do."

+1.

What we did in-house is conduct basic/foundational Computer Security training with our UI/UX guy so he is aware of the concepts and how hard they are, and why the design should be KISS (Keep it simple, stupid)  In the end its a security tool with attention to an awesome user experience (UX)

This research material can help, which combines elements of UX design and security:
https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/akhawe

-Ron F. del Rosario

From: Daniel Kahn Gillmor <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 2, 2014 at 11:10 AM
To: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [saag] opportunistic security again

If an OS-based

--dkg

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 18:28:07 -0400

> authentication is actually used.

So I think that you've confused yourself.

If it's opportunistic security, then it didn't use strong authentication,
therefore the prohibition against an indicator does not apply.  If the admin
did anything *AT ALL* (including, btw, in the SSH TOFU, typing "yes" to the
public key prompt), then it is no longer opportunistic; the key is locked down.

About 70% of the reviewers of RFC4332 would get confused about this, and it's
why it took 2 years to get the document through.

    > read to prohibit this change.

yes, but when in the "OTR in use case", the remote user gets no additional
privileges.

(In fact, in the authenticated case, they also get nothing more, but that's
besides the point)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 18:30:58 -0400

> infrastructure part.  We all know it's easier to attack infrastructure, so it's
    > really important to protect it.  My question here is to figure out if
    > we think

I think you jumped on the word "infrastructure" and starting thinking
integrity of BGP and DNS and the like.

In the original context, it's simply that the opportunistic system MAY
require some supporting actors ("infrastructure") for it to work, such as DNS
or TLSA or DNSSEC or ... and that those components need to be understood as
being part of that system.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Jul 2014 22:31:36 +0000

> If it's opportunistic security, then it didn't use strong authentication,

Sorry, that is not the case.  Please read the draft.  Rather, OS
might not use strong authentication with some peers, but some other
peers may be strongly authenticated (e.g. opportunistic DANE TLS,
for those peers that publish usable TLSA records).

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Jul 2014 23:32:47 +0100

Michael,

On 02/07/14 23:28, Michael Richardson wrote:
> then it is no longer opportunistic;

That "it" is ambiguous. The putative protocol in question
still does support OS, but in that particular run of that
deployment, it may be authenticating one or more endpoints.

I don't think its really useful to talk about the latter
as if its not OS. I think we'd be better off talking about
such cases as being more than OS.

S.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 18:36:20 -0400

Paul Wouters <[email-masked]> wrote:
    >>use of encryption
    >> in the Internet. Protocols that exhibit opportunistic security MUST
    >>attempt to effect encryption of traffic, but SHALL fall back to
    >>plaintext transmission if a

    > No this is wrong. If someone publishes a DANE or IPSECKEY record, and a
    > client can validate that using DNSSEC, it MUST NOT fallback to
    > plaintext.

RFC4332 says that is a local policy (speaking for IPSECKEY/TXT).
You might want to say such a thing for a new IPSECKEY based IPSEC OE
protocol; but as far as I have read, nothing is said.

As for DANE and TLSA; I don't think that presences of a DNSSEC signed key
forces the browser to use HTTPS over HTTP.  There are other mechanisms to
say that, but my IETF-specification-brain-cache is coming up empty right now.

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 2 Jul 2014 18:53:34 -0400

> increase security, but never at the expense of allowing communication to 

I wonder if we have two different ideas of the goal of opportunistic
security in different people's minds.  My earlier impression was that
one of the key problems OS intends to solve is the very common case
where cleartext communication ends up happening now even though some
form of unauthenticated encryption would be possible.  However, this
version of the definition seems to neglect or even contradict that.

In other words, the main point is less "get the best security you can
but allow communication regardless, even if it's cleartext". The main
point is more "don't let the perfect be the enemy of the good - allow
encryption if you can, even if it's not authenticated or otherwise
ideal; some encryption, if posssible, is better than cleartext."

Both of the above ideas seem to me goals of opportunistic security,
but I think the latter is the more important one (since the former
is something we already mostly do on the Internet), while I think
this definition focuses on the former and leaves out the latter.
  -- Cos

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Jul 2014 23:08:00 +0000

> such cases as being more than OS.

It is important to not put an artificial ceiling on the effective
security that can be achieved with OS.  OS sets a low floor and
works up from there on a peer-by-peer basis.  Therefore, strongly
authenticated connections are still OS (not "stonger than" OS)
provided the use of strong authentication is itself opportunistic
(e.g.  conditioned on securely advertised peer capabilities, e.g.
via DANE).

It should also be noted that whether DANE authentication, for
example, is opportunistic or static security policy is application
and configuration dependent.

With SMTP, where transport security has been opportunistic for a
couple of decades, DANE authenticated TLS is also opportunistic.
The presence of TLSA records need not imply a mandate to encrypt
for every application protocol, but it is a strong signal of peer
TLS support, and OS application protocol standards that support
DANE ought to consider requiring TLS when relevant usable TLSA
records are available.

The above is I think too specific for the draft, the goal is to
define broadly applicable principles.  If the draft is not sufficiently
clear on the goal of not capping OS at unauthenticated encryption,
that text may need to be amplified.  My hope is that a careful
reading of the existing text makes the point clear.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 03 Jul 2014 00:11:43 +0100

> authenticated connections are still OS (not "stonger than" OS)

Fair point. As we're seeing again, its not simple to get that
clear and correct.

S.

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 16:10:42 -0700

> version of the definition seems to neglect or even contradict that.

I don't see how...

> but allow communication regardless, even if it's cleartext".

Yes.

 > The main

In that case, the best protection you can get is "some encryption", 
which is what you'd get. I.e., that's 100% consistent with the 
definition I provided.

> this definition focuses on the former and leaves out the latter.

I don't see the difference.

Joe

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Jul 2014 23:13:17 +0000

> this definition focuses on the former and leaves out the latter.

The design principles in section 2 of the draft are ordered with
care.  The first principle covers "both" halves of the suggested
glass half-full, glass half-empty dichotomy.

    Interoperate to maximize deployment:  The primary goal of designs
      that feature opportunistic security is to be able to communicate
      with any reasonably configured peer.  If many peers are only
      capable of cleartext, then it is acceptable to fall back to
      cleartext when encryption is not possible.  If authentication is
      only possible for some peers, then it is acceptable to
      authenticate only those peers and not the rest.  Interoperability
      must be possible without bilateral coordination.  Applications
      employing opportunistic security need to be deployable at Internet
      scale, with each peer independently configured to meet its own
      security needs (within the practical bounds of the application
      protocol).  Opportunistic security must not get in the way of the
      peers communicating if neither end is misconfigured.

-- 
	Viktor.

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 2 Jul 2014 20:07:21 -0400

> which is what you'd get. I.e., that's 100% consistent with the 

Okay, it sounds like we're not dealing with two different views of
what OS is about.  You agree with the view I described, so we're
consistent on that.

Goal A: Encrypt when possible, but don't let that prevent
communication.  If the choice is between cleartext vs. don't
communicate, choose cleartext, but if encryption is possible,
use it.

Goal B: Some encryption is better than none, and encryption without
authentication is better than cleartext without auth.  Do the best
you can, but avoid setting a high minimum standard such that you fall
back to cleartext when that high standard cannot be met, even though
some encryption would be possible.

These are overlapping goals, or overlapping pieces of the overall
goal.  IMO Goal B is the bigger piece.

> >>increase security, but never at the expense of allowing communication to

This definition repeatedly calls out and emphasizes Goal A:

"while still supporting communication."

"Communication security systems have traditionally focused on ensuring
 some set of particular protections, even if those guarantees prohibit
 communication in some cases."

"never at the expense of allowing communication to proceed."

This definition never explicitly invokes Goal B.  It never alludes to
the fact that a lot of communications today falls back to cleartext
because a higher standard of security cannot be met, even though some
better-than-cleartext security is possible.  In other words, that this
does *not* come "at the expense of allowing communication to proceed,"
it comes at the expense of not encrypting where that could be done.

This definition never directly emphasizes the situation where we have
a choice between better security or some security and it's important
to choose some security rather than none in such cases.  It's implied
by "applies the strongest security possible" and "are optimized to
increase security," but both of those are relatively vague and only
indirectly invoke Goal B.  Someone unfamiliar with the context could
easily be forgiven for reading this definition and coming away with
only Goal A in mind.
  -- Cos

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 17:22:10 -0700

> communicate, choose cleartext, but if encryption is possible,

Goal A ignores "do the best you can". It just says "encrypt when 
possible". There's a spectrum of what's possible - including plaintext. 
The goal is really to do the best you can with security without ever 
saying "I can't do X, so I won't do anything".

> you can,

I would stop right there.

> but avoid setting a high minimum standard such that you fall

Right - the point of OS is to prioritize as follows (lower number is 
higher priority):

	1. communicate!
	2. protect a little
	3. protect more...
	N. protect the most

You're supposed to go down the list until you can't satisfy the next 
item, then back up to the one you can. I.e., you never trade security 
for communication.

> goal.  IMO Goal B is the bigger piece.

The first part of B is all you need.

>>>> use at the time invoked while still supporting communication.

"strongest possible" + "while still supporting communication" is the 
same as the first part of B above. I don't think the rest of B is needed.

> "while still supporting communication."

A ignores:

	- "strongest possible" (in my core definition)
	- "optimized to increase security" (in the further discussion)

So I see the description I gave as supporting the first part of B.

> This definition never explicitly invokes Goal B.

The "Communication security" sentence doesn't, but it's a 
counterexample. The other two sentences do, as noted above.

> It never alludes to

But it doesn't really; when configured to use security, it falls back to 
"don't communicate".

> better-than-cleartext security is possible.

True, but I think I already addressed this.

> In other words, that this

It really does; IPsec doesn't backoff to cleartext. Email configured to 
use SSL doesn't backoff either.

The only stuff that backsoff to cleartext (STARTTLS that fails) is doing 
so because there is no other level of security that the software 
supports. That's consistent with OE, though.

> a choice between better security or some security and it's important

I think it does, but if we need an additional sentence to make that more 
explicit, that's fine too....

Joe

---

From: ianG <[email-masked]>
Date: Thu, 03 Jul 2014 09:59:57 +0100

On 2/07/2014 18:23 pm, Stephen Kent wrote:
> 
>> I agree with Joe that Viktor's draft is a better starting point than
>> Steve's. As for incorporating Steve's history: please don't.

any reference to this latter history?

iang

---

From: ianG <[email-masked]>
Date: Thu, 03 Jul 2014 12:17:22 +0100

Agreed.

> substantially different from how much one peer "trusts" the other.

Right.  Any use of the word 'trust' at a protocol level is likely to be
a chimera, because (a) trust is a human thing, not a protocol agent
concept, and (b) there is widespread use of the term in a deceptive
fashion at the human layer.

> authentication is actually used.

If we want a family of protocols that can range inclusively *and*
transparently from cleartext to unauthenticated encryption to
authenticated encryption, it seems a leap too far to also specify
anything firm about user indicators.

iang

---

From: ianG <[email-masked]>
Date: Thu, 03 Jul 2014 12:30:11 +0100

On 2/07/2014 19:01 pm, Stephen Kent wrote:
> The refernce to "best" is worrisome.

That is the point;  'Best' by definition is subjective.  We are in the
world of compromise, and how design A delivers in contrast to design B
will not be immediately clear nor should be specified overly in advance.

If we wanted an objective term we would add it, but it's now a more
precise protocol.  E.g., in foot races, a personal best time is one
clarity suitable for short races, whereas the marathon is more about
getting to the end than the speed.

For browsing wikipedia we'd prefer anon encryption, and for bitcoin we
want authenticated publication, neither is better until we see more
about the context.

iang

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 10:24:06 -0400

> such cases as being more than OS.

I agree that perhaps "it" is ambiguous.

Of course TLS can be used in many different configurations, and the
same port and application can support many different instances using
different options.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 10:45:38 -0400

> for those peers that publish usable TLSA records).

I think you are trying to say that opportunistically using TLS because
the client saw a TLSA record secured by DNSSEC is Strong Security.

I reread draft-dukhovni-opportunistic-security-00.

It says:
 No misrepresentation of security:  Unauthenticated communication or
      use of authentication that is vulnerable to MiTM attacks is not
      represented as strong security.  Where strong security is
      required, opportunistic security is not a substitute, though the
      underlying mechanisms may in some cases be very similar.

I have more written, but decided it would be best to stop here for now.
I am happy with the draft, btw.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 10:52:27 -0400

> (e.g.  conditioned on securely advertised peer capabilities, e.g.

Okay, so we now have a term we can use "OS".

Now, I think that we need to replace the words "strongly authenticated"
above with something else, as those words are too confusing in this context.

I don't think that the MiTM resistant form of OS process you describe
should be called 'strongly authenticated', because that then confuses
situations where the security was mandated and/or established by chain
to a locally trusted anchor.
(please remember that I'm a PK*I* hater when I wrote this)

I think that the draft should define the term strongly authenticated
as something that is not what you describe, but we need a new term for what
you are describing.

I'm okay with "authenticated OS" or "OAS"...

    > DANE ought to consider requiring TLS when relevant usable TLSA

Right; if I intercept the SMTP connection and remove the STARTTLS option from
the EHLO, the connection probably won't go dark even if the TLSA is there.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 03 Jul 2014 11:04:15 -0400

Ian,
> That is the point;  'Best' by definition is subjective.
Using subjective terms in a standard is rarely a good idea. It means
that different readers may interpret the terms differently, and that
is not good.

Steve

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Jul 2014 17:23:32 +0200

Michael,

We may indeed be confusing ourselves.  OTR does have an indicator and
"what you get" is that lovely padlock indicating that the conversation
is <cough> secure.  We don't have to argue over definitions of what that
is because the user surely won't read any conclusion we might come to.

I took the original comment a slightly different way, however.  Rather
than prohibiting strongly authenticated end points, opportunistic
security has the possibility to introduce additional downgrade attacks,
and that is what must be guarded against.  This is classically easy on
the web since the URIs have been different.  It could be more of a thing
elsewhere, depending on what choices get xmitted in the clear.

Eliot

---

From: Paul Wouters <[email-masked]>
Date: Thu, 03 Jul 2014 11:26:46 -0400

On 07/03/2014 11:23 AM, Eliot Lear wrote:
> "what you get" is that lovely padlock 

Ian Goldberg and team (myself included) have blocked any art attempt at using a _padlock_ anywhere in pidin-otr and libotr.

Any padlocks used has been by third-party UI's against upstream recommendations. Padlocks are completely useless to describe non-binary states.

Paul

---

From: ianG <[email-masked]>
Date: Thu, 03 Jul 2014 16:26:46 +0100

Hello Stephen,

> that different readers may interpret the terms differently, and that

When I read Victor's document [0], to paraphrase, I find that it is a
memo to describe [1] opportunistic security, that which strives to
deliver at least some protection most of the time, within constraints of
broad interoperability and peer capabilities.

If we took out subjectivity, we'd be left with section 3.  I wouldn't
term it a standard, more a guide (and memo sounds good).

iang

[0] Just to be clear;
http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00

[1] with a nod to the current debate, I softened "define" in the
original text.  I think it would be quite an achievement to actually
define opportunistic security.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 03 Jul 2014 11:30:24 -0400

On 07/03/2014 10:52 AM, Michael Richardson wrote:

>> The presence of TLSA records need not imply a mandate to encrypt for every application protocol, but it is a strong signal of peer TLS support, and OS
>> application protocol standards that support DANE ought to consider requiring TLS when relevant usable TLSA records are available.
> 
> Right; if I intercept the SMTP connection and remove the STARTTLS option from the EHLO, the connection probably won't go dark even if the TLSA is there.

I fought about making the presence of a TLSA record mandate encryption. People got all upset about dictating local policy.
Paul Hoffman tried twice to introduce a signaling record (HASTLS was one) to allow a server to specify some expectations.
It went nowhere, and now individual DANE documents are specifying what to do themselves in this case.

Of course, the only thing that makes sense is to hard fail. I believe DANE for SMTP does just that, so stripping out STARTTLS
should not work to obtain plaintext email.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 03 Jul 2014 14:14:49 -0400

Ian,

> broad interoperability and peer capabilities.
Until OS is widely available, "most of the time" it will deliver plaintext
connections :-).
> term it a standard, more a guide (and memo sounds good).
I defer to Stephen Farrell as to the target status for the document. If it
is Informational, then I misspoke when noting the problems with 
subjective terms
in standards. But, I still believe that subjective terms are not 
desirable for
a doc that is intended to convey a clear characterization of a term. 
Guidance is
useful, but clarify is paramount. If we can't be clear about what OS is, 
then we
can still provide a list of mechanisms that are supportive of the 
concept that
we're unable to define :-). Imposing a total order on the list 
introduces subjectivity,
when then engenders a lot of text to explain the rationale used by the 
author to impose
the ordering.

Steve

---

From: James Cloos <[email-masked]>
Date: Thu, 03 Jul 2014 18:17:24 -0400

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> Of course, the only thing that makes sense is to hard fail. I
PW> believe DANE for SMTP does just that, so stripping out STARTTLS
PW> should not work to obtain plaintext email.

It depends on how the sending mta is configured.

With postfix, if one configures:

  smtp_use_tls = yes
  smtp_tls_note_starttls_offer = yes
  smtp_tls_security_level = dane
  smtp_dns_support_level = dnssec

then outgoing mail will defer if the destination has signed tlsa which
is dnssec-bogus or if the destination mta lacks starttls or if the cert
it offers fail to match any of the tlsa.

But that is not the default.  One has to choose that config.

I haven't looked into what the other MTAs do.

-JimC

---

From: James Cloos <[email-masked]>
Date: Thu, 03 Jul 2014 18:34:37 -0400

>>>>> "MR" == Michael Richardson <[email-masked]> writes:

MR> As for DANE and TLSA; I don't think that presences of a DNSSEC
MR> signed key forces the browser to use HTTPS over HTTP.

Nor should it, for cases like http vs https.

But a tlsa on _80._tcp... could be declared an indication that the
server supports rfc 2817 tls upgrade and that the client SHOULD do
such an Upgrade.

That said, I'm sure many would prefer to let the client choose when
and whether to try Upgrade, and thus would be happier if _80._tcp
tlsa declares 2817 support but not 2817 requirement.

Similarly, starttls protocols like ftp or imap may prefer tls only be
required for authenticated connections; those also offering anonymous
ftp, imap, etc may prefer clients avoid tls for the anon connections.
(For anon imap; think of access to public mailinglist archives, such
as ietf, AIUI, plans.)

For other starttls protocols, the existance of a signed tlsa can make
a good indicator that tls is not just supported, but preferred or even
demanded.

-JimC

---

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

> But that is not the default.  One has to choose that config.

The view of the implementor, is that DANE, being a fairly new
bleeding edge feature, is not enabled by default.  However, once
DANE is enabled, authentication is enforced when TLSA RRs are present. 

There is also a "dane-only" level, that can be enabled for selected
peers, which requires usable TLSA RRs or fails.

> I haven't looked into what the other MTAs do.

No other MTAs support DANE yet, I'm hoping the Exim folks will get
on board soonish.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 03 Jul 2014 20:10:19 -0400

> server supports rfc 2817 tls upgrade and that the client SHOULD do

Why not obsolete port 80? Use TLS on 443, even with unauthenticated keys on both sides.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 6 Jul 2014 13:34:37 +0000

> Fair point. As we're seeing again, its not simple to get that

Since it is after July 05, I can no longer submit an update, until
submission is reopened on the 21st.

The tentative update text is below:

+   <t>
+     In summary, opportunistic security is an umbrella term that
+     encompasses protocol designs that remove barriers to the
+     widespread use of encryption in the Internet.  The actual
+     protection provided by opportunistic security depends on the
+     capabilities of the communicating peers; opportunistic security
+     MUST attempt to at least encrypt network traffic, while allowing
+     fallback to cleartext with peers that do not appear to be
+     encryption capable.
+   </t>
+
+   <t>
+     It is important to note that opportunistic security is not
+     limited to unauthenticated encryption.  When possible,
+     opportunistic security SHOULD provide stronger security on a
+     peer-by-peer basis.  For example, some peers may be authenticated
+     via DANE, TOFU or other means.  Though authentication failure
+     MAY be a reason to abort a connection to a peer that is expected
+     to be authenticated, it MUST NOT instead lead to communication
+     in cleartext when encryption is an option.  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.  This
+     design blunder MUST be avoided.
+   </t>

I replaced the perpass draft reference with a reference to 7258
and added the boilerplate 2119 text and reference.  I'll post a
-01 on the 21st or so.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sun, 06 Jul 2014 12:13:10 -0400

That update text has the right feel.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Jul 2014 17:54:53 +0100

Hiya,

> submission is reopened on the 21st.

Assuming Viktor can do it, (can you?) would anyone object if I
ok'd publication of the -01 and started a 4 week IETF LC on that?

If you would object, please say so (and why) by Tuesday. (If you
can't get to it by then, and we start IETF LC, then please do send
your comments as part of that LC, and feel free to berate me for
being hasty as part of that:-)

I think we're down to polishing here really so we might as
well get on with the IETF LC spanning the IETF meeting and see if
that generates much or any discussion.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Jul 2014 17:32:43 -0400

> being hasty as part of that:-)

I would prefer to create a sub-term/adjective (FOO OS, Opportunistic FOO
Security, OS FOO) to OS, to distinguish between an unauthenticated encryption
(where failure to cleartext is reasonable), and the "stronger" very where a
MITM can be detected by TOFU, DANE, etc.

HOWEVER: I think that we can define those terms in another document,
and let this one out as-is.

use it in a sentence:
    "yeah, Mr. CEO: our system had detected that it could do FOOSTRONGER OS,
    but the receiving end had rekeyed unilaterally, and so we had to wait for
    the TTL on the TLSA record to expire before your email to example.com
    could be delivered securely"

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 6 Jul 2014 23:55:10 +0000

> and let this one out as-is.

I think this will happen naturally as various opportunistic security
specifications are developed in application specific standards.
For example, the DANE SMTP specification talks about "opportunistic
DANE TLS", which is a flavour of opportunistic security.

> ok'd publication of the -01 and started a 4 week IETF LC on that?

How do I go about submitting it?  Email you the ".xml" file?

> That update text has the right feel.

Thanks.  I tried to combine the feedback to -00 into a coherent
whole.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Jul 2014 00:42:27 -0500

> yes, but when in the "OTR in use case", the remote user gets no additional

In this case "privilege" is strictly in the minds of the users who are
instant messaging.  It's not about privilege but about UIs: how to
inform the user that the peer is not strongly authenticated.

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Jul 2014 00:45:54 -0500

> for those peers that publish usable TLSA records).

Agreed, but do note that when OS yields strong authentication this is
meaningless unless there's a UI element (e.g., future failure when
strong authentication of the same peer name cannot be obtained, and/or
perhaps a UI element to indicate the authentication status of a
"connection"/"session"/whatever.

I.e., OS sets a floor of protection relative to passive attackers, but
to opportunistically raise the floor to protection against active
attackers has UI considerations.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Jul 2014 07:29:18 +0000

> attackers has UI considerations.

Not necessarily, SMTP opportunistic DANE TLS has no UI.  Rather,
the goal is resist MiTM when possible, and secondarily to log the
resulting protection level.  Unauthenticated opportunistic TLS is
vulnerable to MiTM, opportunistic DANE TLS is MiTM resistant.

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Mon, 07 Jul 2014 10:07:20 +0100

> ok'd publication of the -01 and started a 4 week IETF LC on that?

No objection, go ahead.

> that generates much or any discussion.

I have no objections.

iang

---

From: Derek Atkins <[email-masked]>
Date: Mon, 07 Jul 2014 08:35:18 -0400

> +     design blunder MUST be avoided.

I like this text. 

Thank you!

> and added the boilerplate 2119 text and reference.  I'll post a

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Jul 2014 18:19:42 +0100

Hiya,

> How do I go about submitting it?  Email you the ".xml" file?

That's done now and -01 is posted. [1] As the plan is to start
a 4 week IETF LC for that tomorrow (barring good objections)
probably better to hold your comments/text tweaks for a day
and post them on the IETF LC thread. Much easier to track 'em
that way.

Anyone feeling in the mood to be doc shepherd for this? If so,
I'll be after a shepherd write up tomorrow, but that's pretty
simple if you've done it before, though this one could generate
some discussion during IETF LC I suppose, so fair warning if
you do volunteer:-)

If you're up for it, please just mail me off-list.

Thanks Viktor for the quick turn around and thanks in advance
to all who volunteer to shepherd,
Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Jul 2014 18:30:21 +0100

On 07/07/14 18:19, Stephen Farrell wrote:
> 
> Anyone feeling in the mood to be doc shepherd for this?

That was quick! Thanks Paul.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Jul 2014 12:47:37 -0500

> vulnerable to MiTM, opportunistic DANE TLS is MiTM resistant.

Right, sorry, that's like the third time I make that braino.

UIs are only needed for OS when there's no mechanism like DANE for
securely discovering a peer's ability to strongly authenticate.

---

From: James Cloos <[email-masked]>
Date: Mon, 07 Jul 2014 15:25:18 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> SMTP opportunistic DANE TLS has no UI.  Rather, the goal is resist
VD> MiTM when possible, and secondarily to log the resulting protection
VD> level.

Some will consider forensics -- including logs -- to be a UI element for
purposes such as this.

-JimC

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 7 Jul 2014 15:40:18 -0400

I like Viktor's new text, and two reasons I like it are:

1. It makes clear that one of the main goals of work on opportunistic
   encryption is to avoid the (now common) situation where lack of
   authentication capability leads to lack of encryption even though
   encryption capability does exist.

2. It's deliberately broad and... strategically imprecise?  Something
   like that.  It doesn't try to pin down requirements and UI elements
   the way a specific protocol would have to, so that it gives us a
   term that describes a broad strategy into which different
   approaches can fit.  Each protocol may make different trade-offs.

  -- Cos

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Jul 2014 23:17:29 +0000

>    approaches can fit.  Each protocol may make different trade-offs.

I am pleased to see both points are sufficiently clear, and yes
"strategically imprecise" is indeed intentional.

-- 
	Viktor.

---

From: Henry B Hotz <[email-masked]>
Date: Mon, 7 Jul 2014 17:48:59 -0700

On Jul 7, 2014, at 4:17 PM, Viktor Dukhovni <[email-masked]> wrote:

> "strategically imprecise"

I think that term will see wider use, though hopefully no more that OS itself.

+1 on the new text, and I like the 01 draft.

Personal email.  [email-masked]

---

From: Tom Yu <[email-masked]>
Date: Mon, 07 Jul 2014 21:52:03 -0400

> I think that term will see wider use, though hopefully no more that OS itself.

I believe this is also known in broader contexts as "diplomatic
ambiguity" or "constructive ambiguity".

---

From: ianG <[email-masked]>
Date: Tue, 08 Jul 2014 11:55:53 +0100

> ambiguity" or "constructive ambiguity".

That all fits nicely with win-win negotiation;  You need the openness of
ambiguity to find the solutions from exchange of interests, rather than
headbutting with positions and discovering it hurts.

iang