Re: [Mtgvenue] Australia and its encryption laws

George Michaelson <ggm@algebras.org> Thu, 10 June 2021 22:53 UTC

Return-Path: <ggm@algebras.org>
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 0CE8A3A1D9F for <mtgvenue@ietfa.amsl.com>; Thu, 10 Jun 2021 15:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
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 anD729NJfwHA for <mtgvenue@ietfa.amsl.com>; Thu, 10 Jun 2021 15:53:15 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CB03A1D9B for <mtgvenue@ietf.org>; Thu, 10 Jun 2021 15:53:14 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id f30so5706392lfj.1 for <mtgvenue@ietf.org>; Thu, 10 Jun 2021 15:53:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U7lY04P0/DTeBOzP5KP1FJ4WmzSor1kxnrxVoppXHF8=; b=0tp+QoupaIfIUzHGyypjtz56ZpT+LyrpMqKzzPk1sn+iEQDtWFi9gAIC+xk201Os4k +hBVVpLZUvUboitnm4EnP/enH0Yw8zqRaPbC+LXUQJTtlJt4cxPc40Sm/x0YC8CGZTzC IZCklup17cPwNjUWLGM1SlPNTy0nSJRxXwjTVZMxpls2y7sqWPm/kGt7lO47B/6VemF2 FTK6U2AqV0EFaiK7s+Yke+vF9HKkoDbXxQw8GmdZEkjuN7HHY4gNzTHCPg/uK0TTvP4G ix3+/wZGBvPsBSH/3O5wbEus4xFigb5Y4LlzOoC4iEHmBm71cckCoPdwEAmDKvstdu3Q yzYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U7lY04P0/DTeBOzP5KP1FJ4WmzSor1kxnrxVoppXHF8=; b=Fp/JQ/OPj+hrzOebQuoTvynuqEcVNFM/fjmBKf5RcuMDlPvoXRtLXKpqVle4ODQYa9 HhUSI6gUGTf3SJLHH9EgwIW7lTgwMM+iAmvqII0srJY/zdvwqtUSbZNq8hLfqYpjLVfh 9G1QrrDvvkSEKn12Nk3mvsIgFjt6AExPqB1k+7sBqnNqNLmKaAEh6F3coJKbHJK/Ra4j Y1KSlJ8DVwvtNJndYEijHN9AujsOD7j5zN+u0anaTKEwfVEg40WaMN6ZUhUtPppx6qMu 9yKb6aU3azr+qCoVH6dCQpWdBQCziuRzH1pKD/yIEb2Yu9DhrEsO4lbvrK/LaXrexOWa qFGA==
X-Gm-Message-State: AOAM530Vy4I2Txl29NhxpIfmhlUYrLYZcaOMVccUMzdgKnUGSrnjkOEX e+CNsHLtB6H292oEL+SldKNL1vAcQ0qy4EU5HtqXuiB0wSk=
X-Google-Smtp-Source: ABdhPJwgDqNskYTF0e3Z5mpffGL+OQz45Z7CggUQ38yFmmIsfSWvTGS0Ibkd7d1T6cG1HkFRGxgd7fXfctfUw8Wv0jA=
X-Received: by 2002:ac2:4847:: with SMTP id 7mr641639lfy.97.1623365587781; Thu, 10 Jun 2021 15:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <DD2F3038-F6CB-41B5-854D-D3EED6F7C126@nbcuni.com> <991a83e4-79c2-7f2c-6d56-509d94a43c0b@lear.ch>
In-Reply-To: <991a83e4-79c2-7f2c-6d56-509d94a43c0b@lear.ch>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 11 Jun 2021 08:52:56 +1000
Message-ID: <CAKr6gn3vwQcwjrt6X4cyRQJEKosjhLArDLVMLd1tfhLdUDXEWQ@mail.gmail.com>
To: Eliot Lear <lear@lear.ch>
Cc: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>, Jay Daley <jay@ietf.org>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/DnHb16Xh614TnGAbp5K5jBBULzc>
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 22:53:23 -0000

I live in Brisbane. I have been working continuously online across the
time these laws came into effect.

There has been no significant impact on the local ICT industry, in
terms of use of end-to-end encryption built into product,
self-installed, use of tools like signal, VPNs, GIT, there has been no
ubiquitous reporting of intrusive police action, no canary incidents
worthy of wider discussion.

There is always the possibility this is having an impact under NDA,
but that is true under all economies we consider viable for IETF.

To all intents and purposes, nobody I know in the area we are working
in (governance, standards, technology) has really been adversely
impacted by the laws.

cheers

-George

On Fri, Jun 11, 2021 at 2:29 AM Eliot Lear <lear@lear.ch> wrote:
>
> 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
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue