Subject: [saag] Benoit Claise's No Objection on draft-dukhovni-opportunistic-security-05: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Tue, 25 Nov 2014 02:43:54 -0800

Benoit Claise has entered the following ballot position for
draft-dukhovni-opportunistic-security-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection to the publication of the document, but please engage in the
discussion, and clarify the text.

I don't understand what a "OS protocol" is, for example in section 5
"operational considerations"?
Is this a protocol that follows the OS definition, so that use a
cleartext as the baseline communication security policy, with encryption
and authentication negotiated and applied to the communication when
available?
Or is this one protocol that follows the principles in section 3?

The following point is key to me

 No misrepresentation of security:  Unauthenticated, encrypted
      communication must not be misrepresented to users or in
      application logs of non-interactive applications as equivalent to
      authenticated, encrypted communication.

I would go as far as telling that the communication characteristics
(encrypted with authentication versus encrypted without authentication)
must be clearly labeled to the end user, and not only in a log. Who reads
log files, anyway?
That reminds me of the questions asked during one of the plenaries: are
you in favor opportunistic encryption?
I bet that many people thought: well encryption is good, opportunistic
has got a positive touch. So sure, I'm in favor.
If my mother would see "opportunistic encryption" when communicating with
his bank application, I'm sure she would think: yep, everything is good!

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 10:53:00 +0000

Hi Benoit,

> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

I'll let Viktor respond to that one.

> must be clearly labeled to the end user, and not only in a log. 

We had and have pretty strong consensus I'd say within the
security community that the lock icon and security warnings
in browsers have were bad ideas. And people have done a
bunch of studies on that. (Can go find references or explain
further if you're interested).

That is not to say that the lock icon (for authenticated
https web sites) will go away right now, and whether or not
it goes away ever would have nothing to do with this draft,
but measurements show that such icons and warnings are not
understood and counterproductive.

So the current text is really the right thing to say and
ought not change.

> Who reads

Many applications have no UI, e.g. mail servers. So the
best the runtime can do is log stuff.

> his bank application, I'm sure she would think: yep, everything is good!

Our fervent hope is that neither she nor anyone else
ever sees that.

Cheers,
S.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Nov 2014 12:13:35 +0100

Hi Stephen,
> Our fervent hope is that neither she nor anyone else
So what should I answer to her when she asks me: is this communication safe?

Regards, Benoit
> .

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 11:17:21 +0000

> So what should I answer to her when she asks me: is this communication

Well you can tell her to call me, but you won't and shouldn't
be telling her anything that relates to this draft:-) (Or at
least, that last is something for which I believe we have
strong consensus.)

S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 25 Nov 2014 06:34:41 -0500

>>> If my mother would see "opportunistic encryption" when communicating
>>> with his bank application, I'm sure she would think: yep, everything is good!

If you want to give an answer to a specific question like this, you
could say something like: "you have no guarantee that any particular OS
communication is safe, OS provides some network-level resistance against
bulk surveillance, but is not intended to defend against a targeted
attacks."

Regards,

	--dkg

PS Can we stop using "mother" as a proxy for "technically
unsophisticated user" please?  There are lots of technically
sophisticated mothers, and lots of technically unsophisticated
non-mothers.  Let's use less traditionally-exclusive rhetoric.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Nov 2014 14:53:08 +0100

> bulk surveillance, but is not intended to defend against a targeted
That's the entire point. You spoke about OS not being safe, but don't 
tell the end user whether his application uses encryption with 
authentication without authentication (except in a log).
Anyway ...
> unsophisticated user" please?
Note that I spoke about "_my _mother".
Btw, I could have written: So what would you answer to me if I would 
ask: is this communication safe?
Anyway, it's besides the point.

Regards, Benoit

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Nov 2014 14:04:49 +0000

> and authentication negotiated and applied to the communication when

Yes, this.

>       authenticated, encrypted communication.

And not this.  Because it seems that protocols don't have user
interfaces, applications do.  So while applications that employ an
OS protocol are advised to follow the principles, the above principle
ventures into application territory and is not directly applicable
to the underlying protocol.

> must be clearly labeled to the end user, and not only in a log. Who reads

What and when to communicate to users is I think a difficult and
out of scope question, but a statement to not misrepresent the
security achieved is reasonably safe, and was broadly requested.

The principle addresses a broadly shared concern that OS could be
used to mislead users into a false sense of security.  The principle
specifically disavows such misrepresentation.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Nov 2014 14:07:15 +0000

[ Sorry for the second post to saag, for Posts to subscribed lists,
  my MUA is set to auto-trim the Cc list and set Reply-To. ].

Yes, this.

-- 
	Viktor.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Nov 2014 15:17:25 +0100

Hi Viktor,
>> and authentication negotiated and applied to the communication when
Thanks.
An extra sentence would be helpful.

Regards, Benoit

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 14:25:49 +0000

Benoit, Viktor,

> An extra sentence would be helpful.

How about we add a term to section 2 such as:

"OS protocol: a protocol that follows the opportunistic approach
 to security described herein"

I think the term is used in >1 place.

Cheers,
S.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 14:42:56 +0000

>  to security described herein"

Being an optimist, I added that to the RFC editor note.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Nov 2014 09:44:57 -0500

I know this is settled, but would like to go back to one of Benoit's questions that doesn't require an update in the draft.  Top posting because it's further back in the thread.

The consensus for displaying icons and HTTPS was that it would only be used for encrypted and authenticated sessions, not for OS or plaintext.  It wasn't that they would go away.  I was part of the small group that discussed this at the STRINT workshop.

To further this response, in implementations, OS is an upgrade from HTTP and not a fallback from HTTPS.  As such, the incremental security would be to the HTTP session (when that's the encapsulated protocol), rather than a redirect to HTTPS for a limited negotiation (no authentication unless that was available - OS will try to negotiate both - I think incrementally when available). 

I hope this is helpful.
Kathleen

Sent from my iPhone

> On Nov 25, 2014, at 9:25 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Benoit, Viktor,
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Nov 2014 15:12:13 +0000

On Tue, Nov 25, 2014 at 09:44:57AM -0500, Kathleen Moriarty wrote:

> (no authentication unless that was available - OS will try to
> negotiate both - I think incrementally when available).

There are a few ways to employ authentication to deal with active
attacks:

    1.  Tamper-resistance:  Make active attacks difficult
	to carry out.

    2.  Tamper-evidence:  Make instances of active attacks
	difficult to hide.

    3.  Integrity-evidence (to coin a phrase): When it happens,
	to be possible, record evidence of channel integrity.

The draft discusses opportunistic authentication with a view to
achieving the strongest of these, i.e. "1".

Without pinning or DANE, ... if one records authentication successes,
but proceeds despite authentication failure, one generally only
gets "3", Sometimes "3" can be upgraded to "2" after the fact if
information is later obtained that the peer ought to have presented
usable credentials.

So, specifically for opportunistic security with HTTP upgrading to
TLS when possible, absent DANE support or pinning, you only get
"3".  You need tamper-resistant signalling whether/how to authenticate
a peer to get "1".  As for "2" that gets us into a tricky space of
forensic counter-measures with which we don't yet have much
experience.

So I hope that everyone reading the draft understands that the
opportunistic authentication described is of the first kind, and
that merely recording authentication successes without a secure
signal of when to require success does not achieve MiTM protection,
it just records some instances when MiTM "was probably" avoided,
without specifically doing anything to avoid MiTM.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2014 10:39:18 -0500

> without specifically doing anything to avoid MiTM.

The language in the draft is a bit abstruse.   To someone who is already familiar with the milieu, it's clear what's being said, but the hope you express above would only be fulfilled for those readers, not for readers who are interested but don't already have a good understanding of the milieu.   If you would like the hope you have expressed to be fulfilled for the latter class of readers, it might be worth taking the email message you just sent and figuring out a way to incorporate it into the document.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Nov 2014 10:56:42 -0500

> That's the entire point. You spoke about OS not being safe, but don't tell
> the end user whether his application uses encryption with authentication
> without authentication (except in a log).

Trying to clarify for Benoît:

- The overall point here is that we use the strongest mechanism we
can, but no less than the weakest we're willing to accept.  When we
want authenticated encryption, we demand that, and won't drop to
unauthenticated, because that won't do.  HTTPS is still HTTPS, but
with OS, some HTTP (non-S) might start using encryption as well.

- If we tell the user anything (see below), and we do that today with
the lock symbol, the green URL-bar icon, and whatnot, we *only* tell
the user about authenticated encryption.  Unauthenticated encryption
will and should be entirely a matter for the wire, not noticed by the
user.

- As Stephen says, studies are clear on this (I've been following them
for years): users misunderstand anything we tell them about security,
and they misunderstand it so badly that indications to users open wide
doors to misleading them into making bad choices[1] -- worse choices
than if we had never told them anything at all.  Unfortunately, that
horse has left the barn: we've been harping on the lock symbol and the
like for so long that even if we should stop using it, fake lock
symbols will continue to mislead users for many years.

I hope this helps.

Barry

[1] This makes Spencer, especially, very sad.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Nov 2014 17:05:10 +0100

Thanks for the clarification Barry.

Regard, Benoit

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2014 09:41:19 -0800

> will and should be entirely a matter for the wire, not noticed by the

The problem with language like this ("will and should") is that it
really does presume to direct user interface design.  Besides ignoring
the problematic human factors history you cited in your note, it might
or might not be a good suggestion.

The current "no misrepresentation" language is bland, conceptual and
reasonable.  It stays away from UI design and merely talks about user
'effects'.  Saying anything else invites UI design debate. This IETF
document should leave such things entirely open-ended.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 17:43:59 +0000

> document should leave such things entirely open-ended.

Fair point.

Amd btw, the iesg just approved that. Viktor's going to
fold in the RFC editor note changes then we'll be done.

Thanks all for your efforts with this.

Cheers,
S.