Re: [Mtgvenue] Australia and its encryption laws

Eliot Lear <lear@lear.ch> Thu, 10 June 2021 16:29 UTC

Return-Path: <lear@lear.ch>
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 8B80D3A0033; Thu, 10 Jun 2021 09:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 OVlNPL8Y2sfK; Thu, 10 Jun 2021 09:29:21 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A953A45C3; Thu, 10 Jun 2021 09:29:20 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15AGTBBp198936 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 10 Jun 2021 18:29:13 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1623342554; bh=ODQ3RgKa5diuXp///QnrXJWkkGRSOMV2EWK1mFr+T4w=; h=To:References:From:Subject:Date:In-Reply-To:From; b=PbIGYMAz0xN4eTn8jy66NyA6lvntaFE2qu8Z01mHCLatmWmDtoViSn5m/L+p4svVo ePjDsDYTEaMnrgZ5/dCGfCLLLQ3afXxULhGiWYFSy6SHDMf7rGobHS3tf8Cs4n+PTV 3El/YZv5DzVzhSIrGen6timSS2tdwiF+E5CpEoGk=
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>, Jay Daley <jay@ietf.org>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
References: <DD2F3038-F6CB-41B5-854D-D3EED6F7C126@nbcuni.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <991a83e4-79c2-7f2c-6d56-509d94a43c0b@lear.ch>
Date: Thu, 10 Jun 2021 18:29:10 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <DD2F3038-F6CB-41B5-854D-D3EED6F7C126@nbcuni.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="JyenmaO1uT346wOzVzL692pQkaHoPnV3F"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/XoqHeocg1Ls7qhSfXH1Am4ttJHE>
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 16:29:27 -0000

Hi Glenn,

On 10.06.21 17:57, Deen, Glenn (NBCUniversal) wrote:
>
> The article is from 2018, so there’s now been several years for any 
> actual fallout to visitors and others to occur.
>
> In that time has there actually been any legal actions that have 
> actually come to impact visitors to Australia?
>
That would be very useful to know.  As a reminder, the LLC is expected 
to look at this issue through the lens of RFC 8718. Section 2.2 of that 
document governs venue selection and has this to say about policies:

    Politics:
       Endorsing or condemning particular countries, political paradigms,
       laws, regulations, or policies.

The IETF policy is explicitly and emphatically *not* whether we like the 
policies of governments around encryption, but whether those policies 
will materially impact our ability to have a successful meeting.

We also say this:

    Internet Access:
       As an organization, we write specifications for the Internet, and
       we use it heavily.  Meeting attendees need unfiltered access to
       the general Internet and their corporate networks.  "Unfiltered
       access", in this case, means that all forms of communication are
       allowed.  This includes, but is not limited to, access to
       corporate networks via encrypted VPNs from the meeting Facility
       and Hotels, including Overflow Hotels.  We also need open network
       access available at high enough data rates, at the meeting
       Facility, to support our work, which includes support of remote
       participation.  Beyond this, we are the first users of our own
       technology.  Any filtering may cause a problem with that
       technology development.  In some cases, local laws may require
       some filtering.  We seek to avoid such locales without reducing
       the pool of cities to an unacceptable level by stating a number of
       criteria below, one mandatory and others important, to allow for
       the case where local laws may require filtering in some
       circumstances.

I would read the term "filtering" to also include preventing people from 
using the software they wish to use.  But I cannot see whether Australia 
is doing that.  If people cannot bring encrypting software into 
Australia, that's a reason not to meet there.  Similarly, if the 
networking team does not have the technical capability to deliver the 
meeting based on Australia's laws, that would also be a reason not to 
meet there.  These pragmatic matters and perhaps similar potential 
impediments are what the LLC should be looking for at this stage.

For those who would like to take up a policy change about how we select 
venues, that requires an update to 8718.

Eliot