Skip to main content

Further Securing Zoom Meetings

In an effort to ensure the security of our online meetings, ICANN is making several changes to our Zoom configuration. The majority of these changes are behind the scenes and will not greatly impact a typical user’s experience in Zoom. However, there are a few important updates to take note of.

The largest update is the one to the Zoom client, which was released on Monday, 27 April. This patch, dubbed Zoom 5.0, includes an overhaul of the encryption used in the Zoom application. Zoom will no longer operate using 128 or 256-bit ECB encryption, generally considered to be a weak method, and will instead make use of 256-bit GCM encryption, a stronger and far more preferable method of encryption. For a full breakdown on the type of encryption Zoom 5.0 uses, as well as any of the other updates in Zoom 5.0, we’d recommend taking a look at Zoom’s documentation.

Zoom plans to cut overall service to Zoom 5.0, and will be requiring users to update by 30 May 2020. Zoom will be working diligently over the course of this month to ensure that their immense user base is moved over to 5.0 as smoothly as possible.

On the individual account level, Zoom has made available the option to upgrade our own instance before the 30 May deadline, and ICANN has decided to do so. Our primary motivation is, simply put, increasing the security of our online meetings. By moving to GCM encryption, we are taking the best possible step towards ensuring peace of mind whenever we join a Zoom call.

Further, we intend to perform stringent testing of the new version of Zoom prior to ICANN68. Our goal is to hold yet another successful virtual meeting under even more physical restrictions than those we faced during ICANN67. The sooner we begin this testing the better, as it gives us more time to work out any kinks in the system. With this in mind, we are moving swiftly, and all users joining ICANN Zoom meetings will be required to update to Zoom 5.0 no later than 6 May. Updates are available for all platforms and can be accessed on Zoom’s download page.

We have made a number of alterations to our account settings as well. The most impactful change is the new requirement that all meetings be secured with a password. This is the first step recommended by security professionals to keep meetings secure, and one which we had largely adopted org-wide prior to making it a requirement for all. We will make another announcement in the coming weeks regarding how this may impact joining meetings during ICANN68, as we work towards the best overall solution.

If you have any questions about other changes to our account, or about Zoom in general, please get in touch with your usual staff liaisons or email mts@icann.org. We will make sure you get the answers you are looking for.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."