Re: [saag] Is opportunistic unauthenticated encryption a waste of time?

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 22 August 2014 14:00 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553D61A0438; Fri, 22 Aug 2014 07:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAOONjFMdwWx; Fri, 22 Aug 2014 07:00:02 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC241A03FE; Fri, 22 Aug 2014 07:00:02 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CDDF2AB173; Fri, 22 Aug 2014 14:00:01 +0000 (UTC)
Date: Fri, 22 Aug 2014 14:00:01 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org, saag@ietf.org
Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time?
Message-ID: <20140822140000.GE14392@mournblade.imrryr.org>
References: <CAMm+Lwh1xzaxqqnnbdgFQrR0pWknsHru8zjnjCMVjihymXtKNw@mail.gmail.com> <alpine.LFD.2.10.1408202100590.6648@bofh.nohats.ca> <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <CAMm+LwhmJpnU8E9ifA47baneGB=qjHzU_cy+wepPYLXrOhB+Pg@mail.gmail.com> <20140821160402.GT14392@mournblade.imrryr.org> <f5d8b5dc37b84f709c8f2df7c7a69daf@AMSPR06MB439.eurprd06.prod.outlook.com> <CAK3OfOgZzoXVnrE8Nbs6mwN2xD_snbzH9jT8TsYOVt8UASahYQ@mail.gmail.com> <a354d63505924d76a15b505e60e27a16@AMSPR06MB439.eurprd06.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a354d63505924d76a15b505e60e27a16@AMSPR06MB439.eurprd06.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/LasSi-Y0PuslmZBTSH88Mf5QRsI
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org, ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 14:00:11 -0000

On Fri, Aug 22, 2014 at 08:11:38AM +0000, l.wood@surrey.ac.uk wrote:

[ top-post rearranged ]

> Nico wrote:
>
> > On Fri, Aug 22, 2014 at 12:25 AM,  <l.wood@surrey.ac.uk> wrote:
> >
> > > Okay, so with opportunistic security, all a man in the middle
> > > has to do is block any communications he can't decrypt, and it
> > > automatically downgrades to select something he can break?
> > >
> > > Ah, there's the opportunity. Got it.
> > 
> > Eh?  The idea is to be downgrade resistant.
> 
> no, it's at encyption above a baseline. assume mitm can't crack
> maximum level,,but can crack baseline and above. if maximum can't
> be negotiated because mitm prevents it , and less is settled for...
> well. may as well have fallen back to clear.

For the record:

OS is primarily about high level security mechanism selection
(cleartext, passive-only, active and passive protection).  The
draft says deliberately little about the fine details of crypto
handshakes, which may or may not support a range of ciphers and
will typically do exactly the same thing when used opportunistically
in an OS protocol as otherwise.

For example, I don't see TLS changing to become opportunistic.
Rather I see higher level application protocols that can employ
TLS using it opportunistically when previously they might have sent
in cleartext.  (Vocabulary point I try to keep straight, "plaintext"
is input to encryption, or output of decryption, while "cleartext"
is unecrypted content on the wire).

OS does not impact the active attacker's ability to tamper with
unathenticated communication.  However, OS encourages authentication:

   * Any currently protected traffic remains protected, OS does not
     trump existing policy that mandates comprehensive security.
     For example, opportunistic security for HTTP does not downgrade
     HTTPS, all it does is upgrade HTTP to resist passive and
     perhaps some day with some peers also active attacks.

   * OS suggests that it is a good idea to employ downgrade resistant
     mechanisms to discover which peers can be authenticated, and then
     authenticate those peers.

It used to be easy to dismiss opportunistic security as a waste of
time, it is now clear to most that it is not.

-- 
	Viktor.