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.
- Adept Encryption: Was: [saag] DANE should be more… Phillip Hallam-Baker
- Re: Adept Encryption: Was: [saag] DANE should be … Paul Wouters
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: Adept Encryption: Was: [saag] DANE should be … Nico Williams
- Re: Adept Encryption: Was: [saag] DANE should be … Dave Crocker
- Re: Adept Encryption: Was: [saag] DANE should be … Scott Kitterman
- RE: Adept Encryption: Was: [saag] DANE should be … l.wood
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: Adept Encryption: Was: [saag] DANE should be … Phillip Hallam-Baker
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Kent
- Re: Adept Encryption: Was: [saag] DANE should be … Viktor Dukhovni
- Re: Adept Encryption: Was: [saag] DANE should be … Viktor Dukhovni
- Re: [saag] Adept Encryption: Was: DANE should be … Nico Williams
- RE: Adept Encryption: Was: [saag] DANE should be … Christian Huitema
- Re: Adept Encryption: Was: [saag] DANE should be … Nico Williams
- RE: Adept Encryption: Was: [saag] DANE should be … l.wood
- Re: [saag]: Review of: Opportunistic Security -03… Viktor Dukhovni
- Re: [saag] Adept Encryption: Was: DANE should be … Nico Williams
- RE: [saag] Adept Encryption: Was: DANE should be … l.wood
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: [saag] Is opportunistic unauthenticated encry… Viktor Dukhovni
- Re: [saag]: Review of: Opportunistic Security -03… Paul Wouters
- Re: [saag] : Review of: Opportunistic Security -0… Stephen Kent
- Re: [saag] Adept Encryption: Was: DANE should be … Stephen Kent
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Theodore Ts'o
- RE: [saag] Is opportunistic unauthenticated encry… Christian Huitema
- Re: [saag] Is opportunistic unauthenticated encry… Nico Williams
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Stephen Farrell
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Viktor Dukhovni
- Re: [saag] Is opportunistic unauthenticated encry… Stephen Farrell
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: Is traffic analysis really a target (was Re: … Eric Burger
- Re: Is traffic analysis really a target (was Re: … Michael StJohns
- Re: [saag] Is opportunistic unauthenticated encry… Dave Crocker
- Re: Is traffic analysis really a target (was Re: … Brian E Carpenter
- Re: [saag] Is opportunistic unauthenticated encry… joel jaeggli
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: [saag] Is opportunistic unauthenticated encry… joel jaeggli
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: Is traffic analysis really a target (was Re: … Mark Andrews
- Re: [saag] Is traffic analysis really a target (w… Henry B (Hank) Hotz, CISSP
- Re: Is traffic analysis really a target (was Re: … Ted Hardie
- RE: [saag] Is opportunistic unauthenticated encry… Hosnieh Rafiee
- Re: Is traffic analysis really a target (was Re: … Brian E Carpenter
- Re: Is traffic analysis really a target (was Re: … Nico Williams
- Re: Is traffic analysis really a target (was Re: … Eric Burger