Re: [obscurity-interest] [ietf-privacy] wrt tcpcrypt and obscrypt

Dean Willis <> Wed, 13 April 2011 04:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3FD9E06AB; Tue, 12 Apr 2011 21:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.349
X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ULkuPGlM9mN2; Tue, 12 Apr 2011 21:58:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E75FAE00BE; Tue, 12 Apr 2011 21:58:38 -0700 (PDT)
Received: by ywi6 with SMTP id 6so141945ywi.31 for <multiple recipients>; Tue, 12 Apr 2011 21:58:38 -0700 (PDT)
Received: by with SMTP id t26mr9482899yhm.164.1302670698979; Tue, 12 Apr 2011 21:58:18 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id h77sm126380yhm.0.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 21:58:16 -0700 (PDT)
References: <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-14-93464265
Message-Id: <>
From: Dean Willis <>
Date: Tue, 12 Apr 2011 23:58:14 -0500
X-Mailer: Apple Mail (2.1084)
Subject: Re: [obscurity-interest] [ietf-privacy] wrt tcpcrypt and obscrypt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of communications obscurity and real-time communications." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2011 04:58:42 -0000

On Apr 12, 2011, at 12:16 PM, wrote:
> I don't think it is a trivial matter to have the IETF working on confidentiality & privacy by mandating strong
> encryption in Internet (global) standards.  I suspect the intersection of national laws and  technical standards
> is going to be a difficult road to walk, esp if there is a desire for a global standard.

We should perhaps focus on publishing technically correct standards with as few security flaws and weaknesses as we can manage. Trying to decide whether the specification can be legally implemented in Jurisdiction X, Y, Z, and so on is an impossibly large problem.

In fact, it's possible to have conflicting legal imperatives: for example, European laws on privacy protection might well conflict with Asian or North American laws on interceptibility. I'm expecting IMAP/SSL and SMTP/TLS to become illegal in India any day now, at least when used between mobiles within the country and servers outside the country. But I don't think we'll respond by deprecating either specification. If India wants to ban VPNs, they can do that too. But at least the users will know that their privacy is at-risk and economic pressures can be brought (what multinational would put up with this?) to end the ban.

But if we deliberately design security weaknesses into protocols (or continue to tolerate and maintain known problems for which we have a solution), we're arguably negligently responsible for a whole lot of problems.

Dean Willis