Re: [obscurity-interest] [ietf-privacy] wrt tcpcrypt and obscrypt Sun, 17 April 2011 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 500CEE06BD; Sat, 16 Apr 2011 17:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VIhcN83h5Vrj; Sat, 16 Apr 2011 17:52:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 892ADE066A; Sat, 16 Apr 2011 17:50:44 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.12.8/8.12.8) with ESMTP id p3D90Cvn011734; Wed, 13 Apr 2011 09:00:28 GMT
Received: (from bmanning@localhost) by (8.12.8/8.12.8/Submit) id p3D8xfg6011733; Wed, 13 Apr 2011 08:59:41 GMT
Date: Wed, 13 Apr 2011 08:59:36 +0000
To: Dean Willis <>
Message-ID: <>
References: <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
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: Sun, 17 Apr 2011 00:52:05 -0000

On Tue, Apr 12, 2011 at 11:58:14PM -0500, Dean Willis wrote:
> 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.

	no problem with that... however - at least in the US and as a US national, I don't think I can
	(with out filing forms and getting permission -ahead- of time) work on confidentiality/privacy, 
	techniques in an open forum.  and I am pretty sure that other sovreigns have the same issues.

	DNSSEC avoided this problem by explicitly not supporting confidentiality.  Thats the only way
	it made it past export (from the US) and import (into other places).

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

	its not just the code, its illegal to share work on some of these topics in some venues.
	this is a topic that -REALLY- needs to have the ISOC/IETF legal team look at closely before
	we engineers go off half-cocked and get ourselves, our employers, and the IETF into international
	legal trouble.

	an modicum of prudence would not be amiss here.  (and for a brief nostalgic note - the Danvers IETF
	plenary was a mtg not to be missed)

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

	yes.  if you think that lack of confidentiality is a weakness, then you might be right.
	in an ideal world, where strong crypto - used for confidentiality was acceptable w/o 
	restriction in every country in the world - we would still end up with the "arms" race of 
	keeping up with larger salts, new algorithms, and backward compatabilities...  

	can we move that fast and -NOT- have a long tail to drag around?  I've not seen it done.


> --
> Dean Willis