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
- 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