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

Hosnieh Rafiee <hosnieh.rafiee@huawei.com> Mon, 25 August 2014 08:09 UTC

Return-Path: <hosnieh.rafiee@huawei.com>
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 019881A6FEB; Mon, 25 Aug 2014 01:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 eMe-dpjJya4C; Mon, 25 Aug 2014 01:09:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6575B1A0047; Mon, 25 Aug 2014 01:09:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIR88849; Mon, 25 Aug 2014 08:09:08 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Mon, 25 Aug 2014 09:09:05 +0100
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: "saag@ietf.org" <saag@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: [saag] Is opportunistic unauthenticated encryption a waste of time?
Thread-Topic: [saag] Is opportunistic unauthenticated encryption a waste of time?
Thread-Index: AQHPvhF6o3esl+HxrEicw4IqjGmjzJvdYuAAgAAfSACAARJeAIAAAY+AgAAI2YCAAR6TAIABN0BA
Date: Mon, 25 Aug 2014 08:09:04 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A290F5@lhreml513-mbb.china.huawei.com>
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> <53F9F268.1030407@si6networks.com>
In-Reply-To: <53F9F268.1030407@si6networks.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/K1tN9832pE-Q7lQ5WpOYYKwkQJ8
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: Mon, 25 Aug 2014 08:09:12 -0000

> It is quite often the case that, under oppressive regimes, using
> encryption technology will already flag you as "suspect" (if not
> "guilty"). So in that case, you'd probably want to use something
> probably want something more like a cover channel in those scenarios.
> 

To some extend I agree with Fernando since I have the practical experience of such places. To be clear, if the purpose of the encryption is to avoid such places to access users' data or try to harden this process, actually it fails because the users force to use their devices and the main internet stream to those countries passed by their devices (where all traffic filtered and analyses and then sent to the users). Therefore, you cannot help them, especially, if you're talking about unauthenticated source of data. When OS or other ways try to help to authenticate this data, then maybe you can be 1% successful. Because this also helps that the users do not recognize this MITM attack. They can recognize this when they receive any warning message. (I am not talking about professional users that might trace their traffic. But about 80% of internet users.)

Nevertheless, In my opinion, encryption, in general, is good. But it depends on what our target users or services are and who we want to hide this traffic from. Whether those people have access to the main internet stream and the user have no way to avoid them? Whether they have a power to apply regulation for internet in a country and user MUST follow them? Or whether they only want to sniff data passively in a way that user do not recognize it. In last case, encryption conditionally can be successful but I do not think it works in the first two cases. 
The conditions are that 1- whether those places can be easily recognized if they do active attacks? (it might be yes if they want to do this attack with the whole internet data stream that belongs to different countries but this is not true if it is only a small portion of traffic such as an enterprise or etc.)


I hope that I could explain my point clearly.

Best,
Hosnieh