Subject: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Thu, 18 Sep 2014 03:29:37 -0700

Ted Lemon has entered the following ballot position for
draft-dukhovni-opportunistic-security-04: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this document needs to state explicitly that opportunistic
security is _not_ appropriate in the same set of applications as
mandatory security.   E.g., we never want "opportunistic security" when
connecting to the bank, or doing a credit card transaction.   We want
mandatory security.   I think that is so obvious to the security folks
that nobody thought to mention it, but it must be stated in large
friendly letters both in the introduction and in the security
considerations section, because this document will be read by
non-security-geeks.   You should also advise that documents that describe
implementations of opportunistic security should mention this in _their_
security considerations section.   An opportunistically secure protocol
that can be MiTM'd to look secure on the server end whilst being in
cleartext on the client end would be disastrous in such contexts.

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

Aside from issues of accuracy, the choice of the phrase "opportunistic
security" is unfortunate because it leads to abbreviation as "OS" which
is a well known acronym for "operating system," and a slightly less
frequently used acronym for "open source."   I'm not raising this as a
strong objection, because I know this topic was hotly debated during IETF
last call, but the arguments I saw during the debate that it's just not
that important and can't be fixed anyway fall flat for me because of this
problem.   Every time I see "OS support" or something similar in the
text, I read "operating system support," not "opportunistic encryption
support."   If you are going to use this term, I think you should get
over the wish for brevity and just spell it out.  I would call it
"opportunistic protection" or something like that to get a better
acronym.   Nobody's going to read "OP support" as "original poster
support".

In section 5:

   When protection only against passive attacks is negotiated over a
   channel vulnerable to active downgrade attacks, and the use of
   encryption fails, a protocol might elect non-intrusive fallback to
   cleartext.  An active attacker could equally have suppressed the use
   of encryption during negotiation, so failure to encrypt may be more
   often a symptom of an interoperability problem than an active attack.

The last sentence doesn't make sense—the first half of the statement
doesn't actually imply the second half as a conclusion, as the "so" in
the middle would suggest.   It implies the opposite.   I don't think you
are saying anything wrong here, but you need to clean this text up,
because as written it doesn't make sense.

When the DISCUSS is cleared, I will change this to a no objection, but
while I don't necessarily agree with Barry's remedy for the DISCUSS, I do
agree with the general thrust of his DISCUSS.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Sep 2014 10:25:03 -0400

On 09/18/2014 06:29 AM, Ted Lemon wrote:

> connecting to the bank, or doing a credit card transaction.

That really comes down to your definition of "application". For example, in an IKE daemon for IPsec, you would be handling both user defined VPN tunnels (to
your bank, your home, your work) as well as OS based tunnels (to hosts you don't have a preconfigured security relationship with). I think your definition of
application would not include the IKE daemon?

But even within an application (browser, mail client, IM client) one could have multiple configurations. I could have IM application which talks using DANE
secured TLS for one XMPP account (eg work), but using OS based security for some public IRC server.

What you really mean to say, which the document does say but perhaps not explicitly enough, is that OS MUST NEVER trump preconfigured authenticated encryption,
and MUST only be attempted if not doing OS would result in communication in cleartext.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 18 Sep 2014 16:09:50 +0000

On Thu, Sep 18, 2014 at 10:25:03AM -0400, Paul Wouters wrote:

> What you really mean to say, which the document does say but perhaps not
> explicitly enough, is that OS MUST NEVER trump preconfigured authenticated
> encryption, and MUST only be attempted if not doing OS would result in
> communication in cleartext.

Indeed, but somewhat generally:

Basically, OS can raise "the floor" (baseline security policy) but
never lower it.  If local policy or the protocol specification sets
the floor to "unauthenticated, encrypted communication" then OS
might potentially raise that to authenticated, encrypted communication
with some peers.

If, as Paul explains, the floor is cleartext, then OS can exceed
that.  If the floor and ceiling (most you could get) coincide then
there's no room for OS.

Local policy can of course set either the ceiling or the floor,
possibly to the same value, or leave a gap in which OS can operate.

Things like the use of "https" vs "http" URIs are one way of
expressing local policy.

-- 
	Viktor.

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Sep 2014 09:30:30 -0700

> draft-dukhovni-opportunistic-security-04: Discuss
...
> mandatory security.
...

AFAICT you want a mandatory minimum. That may or may not include ID-free 
methods (e.g., BTNS), it may or may not include channel binding and 
higher-level authentication, etc.

AFAICT, OS isn't about just using BTNS-style mechanisms; it appears to 
be about being inclusive of a range of alternatives that the app should 
constrain.

If the doc isn't clear on that point (either agreeing or refuting), it 
should be.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Sep 2014 14:41:04 -0500

On Thu, Sep 18, 2014 at 09:30:30AM -0700, Joe Touch wrote:
> AFAICT you want a mandatory minimum. That may or may not include
> ID-free methods (e.g., BTNS), it may or may not include channel
> binding and higher-level authentication, etc.
> 
> AFAICT, OS isn't about just using BTNS-style mechanisms; it appears
> to be about being inclusive of a range of alternatives that the app
> should constrain.

OS does set a mandatory minimum: the lowest common denominator between
local capabilities and a peer's discovered/advertised capabilities.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Sep 2014 12:54:20 -0700

> local capabilities and a peer's discovered/advertised capabilities.

That's a minimum of what is possible, certainly. A mandatory minimum 
would be established by the "consumer", i.e., the app - i.e., do at 
least this much or don't bother setting up a connection at all.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Sep 2014 15:05:57 -0500

On Thu, Sep 18, 2014 at 2:54 PM, Joe Touch <[email-masked]> wrote:
> That's a minimum of what is possible, certainly. A mandatory minimum would
> be established by the "consumer", i.e., the app - i.e., do at least this
> much or don't bother setting up a connection at all.

Yes, of course, local policy (and, of course, application protocol
specs) set a minimum.  OS can only raise that minimum, not lower it.
The I-D does say this.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 06:20:26 -0400

> specs) set a minimum.  OS can only raise that minimum, not lower it.

There is text in the document that talks about local policy.   There is absolutely no chance that a non-security-expert reading that would take it to mean what I said.   And furthermore, local policy doesn't help if there is no secure way in the protocol to say "encryption is mandatory for this connection."   So this isn't responsive to the point I raised.

I think I was pretty clear in my DISCUSS point, but just to be clearer, it has to be the case that the _client_ can't both know about the possibility of connecting to a security-is-mandatory resource _and_ be fooled about the mandatoryness of security for that resource.   IOW, we do not want to get rid of https://.

I don't think the authors of this document want to get rid of https://.   I just think that the document needs to be clearer about that.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 Sep 2014 14:27:24 +0000

On Fri, Sep 19, 2014 at 06:20:26AM -0400, Ted Lemon wrote:

> There is text in the document that talks about local policy.   There is
> absolutely no chance that a non-security-expert reading that would take
> it to mean what I said.   And furthermore, local policy doesn't help if
> there is no secure way in the protocol to say "encryption is mandatory
> for this connection."   So this isn't responsive to the point I raised.

You, others and I are I think in complete agreement as to when OS
is not applicable, so the question as I understand it is whether
the text sufficiently captures that agreement.

I had hoped that the last paragraph above subsection 1.1 and the
first principle would adequately address this point.

    1.
       ...

       OS is not intended as a substitute for authenticated,
       encrypted communication when such communication is already
       mandated by policy or is otherwise required to access a
       particular resource.  In essence, OS is employed when one
       might otherwise settle for cleartext (or the minimum protection
       possible if the protocol is always encrypted).  OS protocols
       never preempt local security policies.  A security administrator
       may specify security policies that override OS.  For example,
       a policy might require authenticated, encrypted communication,
       in contrast to the default OS security policy.

   1.1.
       ...

    3.
        ...

        Coexist with local policy:  Local security policies preempt OS.
          Opportunistic security never displaces or preempts local
          policy.  Many applications and types of data are too
          sensitive to use OS, and more traditional security designs
          are appropriate in such cases.

There were similar concerns during LC, and the text was amplified
to address those concerns.

> I think I was pretty clear in my DISCUSS point, but just to be clearer,
> it has to be the case that the _client_ can't both know about the
> possibility of connecting to a security-is-mandatory resource _and_ be
> fooled about the mandatoryness of security for that resource.   IOW, we
> do not want to get rid of https://.

Indeed I consider "https://" URIs to be such local policy.  Hence
the phrase "or is otherwise required to access a particular resource"
at in the paragraph above 1.1.

> I don't think the authors of this document want to get rid of https://.
> I just think that the document needs to be clearer about that.

Absolutely correct, there is a well known security policy associated
with an "https" URI, and OS does not preempt that policy.  With
browsers OS could only apply to "http://" and/or any other URI
schemes where it may be appropriate.

In response to the DISCUSS I previously sent the below.  Are you
looking for a more detailed exposition of what "local policy" means?
Would that be examples like "https://" or per destination TLS policy
tables in an MTA, a more detailed general description, or both?

> On Thu, Sep 18, 2014 at 03:29:37AM -0700, Ted Lemon wrote:
> 
> This is difficult to explain, since an MTA is an application, and
> typically supports different policies for different destinations,
> with a default policy for the rest.
> 
> > E.g., we never want "opportunistic security" when
> Absolutely, but sadly for most users connecting to the bank is not
> a different "application", it's all in the browser.  However,
> "https://..." URIs specify a security policy that OS does not
> preempt.
> 
> I think that the first design principle adequately covers this.
> 
> > We want mandatory security.
> 
> Absolutely.  This is, for example, also discussed in the DANE SMTP
> draft which specifically leaves room for mandatory policy, possibly
> with authentication via DANE or via locally configured public CAs.
> 
> > I think that is so obvious to the security folks
> > non-security-geeks.   
>  ... and because local security policies take precedence over the default OS
>  policy ...
> 
>  While the use of OS is preempted by a non-OS local policy, ...
> 
> > You should also advise that documents that describe
> The DANE SMTP document currently has:
> 
>    The protocol does not preclude existing non-opportunistic SMTP
>    TLS security arrangements, which can continue to be used as
>    before via manual configuration ...
> 
> 
> > In section 5:
> > 
> > The last sentence doesn't make sense?the first half of the statement
> > the middle would suggest.
> 
> Yes, the point is that not falling back does not help, and therefore,
> one might as well (when operationally necessary) enable fallback,
> since the active attacker is not deterred by lack of fallback.
> This can be stated more explicitly.
> 
> 
> > It implies the opposite.   I don't think you
> Got it.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 11:41:59 -0400

I think possibly what is missing is simply a clear explanation, probably accompanied by an example or two, of what you mean by "local policy."   I would never normally think of using an https URI as relating to "local policy," although when I read the document I did get a reasonably clear impression that that was how you were using the term.   I think you might want to just use a different term than "local policy."   E.g., "service provider policy."   I think you are trying to avoid opening the can of worms of talking about peer vs. server vs. client, and I understand why you want to avoid opening it, but I think in doing so you are making the document less clear.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 Sep 2014 16:10:20 +0000

On Fri, Sep 19, 2014 at 11:41:59AM -0400, Ted Lemon wrote:

> I think possibly what is missing is simply a clear explanation, probably
> accompanied by an example or two, of what you mean by "local policy."
> I would never normally think of using an https URI as relating to "local
> policy," although when I read the document I did get a reasonably clear
> impression that that was how you were using the term.

Correct, the intention was to sweep all the various flavours of
a-priori security requirements under the "local policy" rug.

> I think you might
> want to just use a different term than "local policy."   E.g., "service
> provider policy."   I think you are trying to avoid opening the can of
> worms of talking about peer vs. server vs. client, and I understand why
> you want to avoid opening it, but I think in doing so you are making the
> document less clear.

Thanks.  I'll endeavour to make this clear in -05.  One option is
to define something along the lines of "explicit policy" (local or
otherwise).  When accessing a resource or communicating with a peer
for which explicit policy sets requirements for either encryption,
authentication or both, then OS cannot preempt such policy to accept
less secure communication, but might achieve more when consistent
with that policy.

I will discuss this with Pete Resnick, who's kindly volunteered to
help with -05.  Will try to more clearly cover both operator
per-destination local policy and policy embedded in resource
identifiers, whether specified locally, or obtained in the course
of interaction with some peer.

You're right, I don't want to take a deep dive into this tangent,
ideally we'll be able to adequately communicate the idea without
too much new verbiage.

-- 
	Viktor.

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Sep 2014 10:59:38 -0700

On 9/19/2014 3:20 AM, Ted Lemon wrote:
> There is text in the document that talks about local policy. There 
> is absolutely no chance that a non-security-expert reading that would
> take it to mean what I said. 
...
> I don't think the authors of this document want to get rid of
> https://. I just think that the document needs to be clearer about that.

AFAICT, this can be addressed in the pending revision. It's one of many
places where the doc could be more clear, even if technically it
addresses the point raised.

Joe