Re: [Mtgvenue] Australia and its encryption laws

John C Klensin <john-ietf@jck.com> Thu, 10 June 2021 23:29 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06ED3A1EA9; Thu, 10 Jun 2021 16:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KmS1MFA5jzsF; Thu, 10 Jun 2021 16:29:53 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FD33A1EA6; Thu, 10 Jun 2021 16:29:53 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lrU7R-0004Tl-EO; Thu, 10 Jun 2021 19:29:49 -0400
Date: Thu, 10 Jun 2021 19:29:43 -0400
From: John C Klensin <john-ietf@jck.com>
To: Adam Roach <adam@nostrum.com>, Jay Daley <jay@ietf.org>, mtgvenue@ietf.org
cc: George Michaelson <ggm@algebras.org>, Eliot Lear <lear@lear.ch>
Message-ID: <0F6579F577258925647BE489@PSB>
In-Reply-To: <d44d108a-e7fe-c71f-7001-ae4a9ffe2b99@nostrum.com>
References: <45CB2336-8E0E-49AE-A625-3F0989EE4CA5@ietf.org> <a9c9622f-b499-f7de-5078-267f76f0530f@nostrum.com> <1F7A2AED46C3513B4F6BD68C@PSB> <d44d108a-e7fe-c71f-7001-ae4a9ffe2b99@nostrum.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/6b3QYxa_JXXsyh7rcxEyHPE3NE0>
Subject: Re: [Mtgvenue] Australia and its encryption laws
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2021 23:29:58 -0000

Adam,

I think you missed my point, for which I acknowledge that this
might not be the right discussion list.  As far as meeting
planning is concerned, I agree with Eliot Lear's rather nice
analysis (posted minutes before your note below) and
appreciation George Michaelson's note posted a few minutes ago.
I would add to both that our own requirements for openness in
conjunction with IETF work (see BCP 78 and assorted "Note Well"
comments) are such that, if it is necessary to protect meeting
materials and conversations from falling into the hands of law
enforcement or the like, we have more serious problems or to
quote a professor colleague from long ago, "maybe they will
learn something".  I can imagine a company being concerned about
an employee conducting confidential company business while at an
IETF meeting, but, we have never made that a criterion for not
holding a meeting and, as Eliot more or less points out,
companies feeling sufficiently secure about their own
communications is not part of RFC 8718.

I was, and remain, concerned about something else, something
that has little or nothing to do with where we hold meetings.
In recent years, the IETF has been very strongly (and
increasingly, IMO) committed to more use of encryption in
support of individual privacy, including privacy from interested
governments.  If Australia's apparently heavy-handed rules
(independent of how they are actually applied) restricts use of
cryptography (or restricts its use without government/ law
enforcement access or back doors) then, if our protocols do not
make provisions that allows people subject to those laws to
conform with them, we are essentially making it impossible for
those people or associated companies to use the Internet while
conforming to our protocols.  That would encourage fragmentation
and/or development of other protocols elsewhere.   It that is
not obviously a good idea (at least to me) and I wish we were
more explicitly considering the tradeoffs involved (thanks to
Eliot for raising a related issue on another list).

best,
 john


--On Thursday, June 10, 2021 09:30 -0700 Adam Roach
<adam@nostrum.com> wrote:

> On 6/10/21 00:08, John C Klensin wrote:
>> It is a slightly different question but, if we accept your
>> description of the "top-line issue" and follow your reasoning,
>> does it not obligate us to be certain that there are
>> plain-text versions of all of our protocols
> 
> 
> No, it does not.
> 
> 
>> Without trying to take a position on Jay's question, my
>> recollection is that we made our meeting in Beijing
>> conditional on unrestricted access to the global public
>> Internet, including the use of encrypted traffic
> 
> 
> And TOLA, of course, does not prevent this. HTTPS, VPNs, and
> the use of other encryption technologies remains legal. For
> the sake of clarity, here's a fairly concise summary of the
> controversial provisions of the TOLA Act:
> https://corrs.com.au/insights/australias-security-monitor-reco
> mmends-changes-to-controversial-anti-encryption-legislation
> 
> It is egregious overreach, of course, but has no bearing on
> the work we do during a meeting. Even in the Kafakaesque
> scenario of Australia attempting to issue a TCN for someone
> visiting for a week, the end result would be meaningless:
> development of the envisioned capabilities happens in weeks
> and months, not hours and days. Setting foot in a country does
> not bind its laws to you forever: I've visited Japan, and yet
> my possession of pseudoephedrine in Texas doesn't put me at
> legal risk from Japanese authorities.
> 
> /a
>