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

Dean Willis <> Mon, 18 April 2011 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 547B6E06FF; Mon, 18 Apr 2011 14:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.498
X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 l6X+ySacbzpK; Mon, 18 Apr 2011 14:24:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D90A3E06F5; Mon, 18 Apr 2011 14:23:54 -0700 (PDT)
Received: by ywi6 with SMTP id 6so1766061ywi.31 for <multiple recipients>; Mon, 18 Apr 2011 14:23:54 -0700 (PDT)
Received: by with SMTP id f40mr4699584agq.185.1303161834164; Mon, 18 Apr 2011 14:23:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id c4sm5800798ana.49.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 14:23:52 -0700 (PDT)
References: <> <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-24-584599253
Message-Id: <>
From: Dean Willis <>
Date: Mon, 18 Apr 2011 16:23:49 -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: Mon, 18 Apr 2011 21:24:02 -0000

On Apr 13, 2011, at 3:59 AM, wrote:

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

Sue you can. You just can't export executable code for a certain subset of applications without prior EAR approval. I'm not a lawyer, but I have coordinated export for a company that was shipping SIP proxies with TLS support for signaling. Actually, it was more like cleaning up the situation for a company that had been accidentally exporting such function without having done all the needed paperwork, but it's clearly doable.

Even in the US, a fairly broad range of applications in unrestricted. This includes a cryptographic applications that do not have generic data-object encryption as their primary function, including crypto for copy protection, digital rights restriction, and arguably (having argued this with apparent success for SIP/TLS) protection of signaling to/from a service platform.

Even exporting products containing the code for general purpose encryption of the sorts used in most IETF specs is a fairly straightforward reporting exercise. If it weren't, you wouldn't see anybody running an Apache web server, and you wouldn't be able to download the J2EE SDK from Oracle//Sun/whatever owns it today.

Yes, Phil Z may have been arrested over PGP, but that was arguably as much an intellectual-property snit with RSA as it was an export control issue. And as you may recall, the case eventually faded away, though things were a bit tense for awhile.

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

The IETF has quite effectively published dozens of RFCs for SSL, TLS, PKIX, DTLS, SRTP/DTLS, and now ZRTP. We've also published lots of higher-level specs that reference these at  a "MUST implement" level. It's been looked at fairly closely. It seems unlikely that we'd be faulted for  pushing the specs a little further to add "MUST NOT implement a null cipher" requirement.

So, Kanuckistan or other locales might restrain their citizens from participation. They probably don't let them leave the country to attend IETF meetings either, so who cares what their rules are? We're not going to force them to develop the capacity to engage in international business; if a nation really wants to be a stagnant backwater with a starving citizenry and intellectually inbred leadership they can just choose not to play along.