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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 23 August 2014 21:33 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 DD34B1A0747; Sat, 23 Aug 2014 14:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 DKYf1hxYhGHX; Sat, 23 Aug 2014 14:33:24 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2A1A0745; Sat, 23 Aug 2014 14:33:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B2D0BE12; Sat, 23 Aug 2014 22:33:23 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nw-8DLtngu9; Sat, 23 Aug 2014 22:33:21 +0100 (IST)
Received: from [10.87.48.6] (unknown [86.41.54.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88FDDBE11; Sat, 23 Aug 2014 22:33:21 +0100 (IST)
Message-ID: <53F908A1.6040207@cs.tcd.ie>
Date: Sat, 23 Aug 2014 22:33:21 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>, Nico Williams <nico@cryptonector.com>
Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time?
References: <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>, <20140822140000.GE14392@mournblade.imrryr.org>, <BLU181-W84354FE6BEF12305A2A7DB93D10@phx.gbl>, <20140823040550.GQ5909@localhost> <BLU181-W307B52819C577693183E2D93D10@phx.gbl>, <53F8FA97.2020607@cs.tcd.ie> <BLU181-W664365D566637BE6D0E67493D10@phx.gbl>
In-Reply-To: <BLU181-W664365D566637BE6D0E67493D10@phx.gbl>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/E3RctWILwslHe6ONCVXiU5rOsG0
Cc: "saag@ietf.org" <saag@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sat, 23 Aug 2014 21:33:26 -0000

Hiya,

On 23/08/14 22:05, Bernard Aboba wrote:
> Stephen Farrell:
>> However, say we're wrong and someone who thinks OS is a waste of
>> time is actually correct, what would such a person recommend that
>> we do as well as, or instead of, OS?
> 
> [BA] It depends on who we are trying to protect, and from what (or
> whom). 

Sure.

> If the target is protection of dissidents from oppressive
> regimes, then you need something much more comprehensive than
> 'unauthenticated opportunistic encryption" (e.g. along the lines of
> Tor). 

Right. That's a hard target and involves far more than crypto,
whether OS or not.

One thing clearly involved there is that traffic analysis is
a threat, and I'd fully accept that we should be thinking about
ways in which we could make our protocols better against that
in general, even if we're not tackling the specific problems of
dissidents. For example, if my toilet emits packets with every
flush, encryption of any sort isn't going to disguise that so
traffic analysis will also be relevant for the Internet-of-Toilets.

> If the target is protection against PM within wealthy nations,
> then you'd need something that can't be rendered harmless by a modest
> budget increase. A number of MITM protection mechanisms have been
> suggested (e.g. DANE, channel binding, etc.). 

But isn't that what the IETF and security folks within the
IETF have been aiming for for a couple of decades? I mean aiming
for an end-state where we have mutual-auth more-or-less everywhere.
I don't consider that we've succeeded wildly to be honest;-)

What should we be doing differently is really my question.

> Also, in this category
> should be mechanisms for protecting privacy against private-sector
> adversaries. As long as private companies can amass huge dociers
> without resort to PM (or without the need to subvert OS), and are
> willing to sell that personal information to third parties (dodgy
> ones, let alone governments),  one wonders whether government
> agencies would make better use of their funds by "buying"
> surveillance, rather than trying to "build" it.

As it happens we had some discussion about e2e email security in
Toronto. Current plan is to start a new mailing list for that - a
bunch of us are chatting about how to scope that so we're less
likely to mess up. (More on that next week I hope.)

Now email is of course just one application (though a cornerstone
application). Which other applications/mechanisms should we be
considering that'd help here? FWIW, I'm very open to us trying to
help anywhere we could credibly do that. (Credibility requiring
that stuff be technically doable, be something that should be done
in the IETF and have enough warm bodies interested in doing work.)

Cheers,
S.

PS: If you or someone has a specific suggestion for a thing on
which we should be working, then maybe these lists are too broad
for detailed discussion of that. In such cases, the perpass@ietf.org
list is probably a good place to triage whether a topic is one we
should try pursue in the IETF.