[Qirg] QIRG meeting minutes

Bruno Rijsman <brunorijsman@gmail.com> Mon, 16 November 2020 08:18 UTC

Return-Path: <brunorijsman@gmail.com>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA7E73A0AB7 for <qirg@ietfa.amsl.com>; Mon, 16 Nov 2020 00:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zZxgkTlykdM7 for <qirg@ietfa.amsl.com>; Mon, 16 Nov 2020 00:18:14 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 0B29D3A0844 for <qirg@irtf.org>; Mon, 16 Nov 2020 00:18:12 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id w24so22762734wmi.0 for <qirg@irtf.org>; Mon, 16 Nov 2020 00:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=cWiihyndKNGFl/FH+C6h/t/zMpHn2OhU9teFRiR8JV4=; b=lwmOaidufkmxQDJMfwNsf0nAcON6aYeS4EIXARgTLKyZTsJCSaFRzc6ZldzjwDbcXA UQtcwA6lJJnLT+ZTSheUsRTObkUJ+lM7fotU2BY/swj5FyLEOSjN0LMoYIXeRrMUvMhE ZDwCiT68JdOI4nZjbGhw2ydYQKa6XVpn+x+NpCtU0Up7aIycm20Qek52n/xRnEzP3Dlo yiFZE4jcUr100+ft2nQMRh2mPqZLqHEO9v8p5Cr6gGlsZbvzbhAnAQR9HpYlLz77Uyp/ a0YHRVxVIXMkKEiPJAu88pRk72ZWfjDu3uewXkpkcLyBuWM5WO3BY3CSB6yBwMPBlUnf vW8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:message-id:to; bh=cWiihyndKNGFl/FH+C6h/t/zMpHn2OhU9teFRiR8JV4=; b=TcDP+nOAJDCRByEFveW55nwCf4hC7BWd1dyaA9UrJKZa1n6jbLpGercpVT0llhdRMu tbjLHebB3eQwZ4MzaaJg0UPxSiE5A3gjtF15XZ1PYovgNLXEoyJDihcl0n2U+qezMutG u50zd93XMQbTO18ce8OAV0xvIXFaXX9o0iEPQ9Ej/WFgIwlgGNN6vjMEgPE7e+jz2ydA 6dBqn4iA5bxFc5Vh6rwA+FnGyaB0wv/WCM7X6+vLtz8ykMuhTEYNpF3yndi8NbshN7ql qwRs7n3oeyX8ifIumq/3+Ok20IXvx3TkBwMwJB0pKnLc3MYrcQwgNxdVbEN7uBbfNLxc fG7Q==
X-Gm-Message-State: AOAM532Gdcb74pEdyE0Kc+H0Wp7DSjJiz5EEgY+cUv+pvE6VCUquTmBM 7vECF1EzBN9vzXh+LTGTbvsAtYEA5jLWKQ==
X-Google-Smtp-Source: ABdhPJwMGgjTvgsgHyvbgsaoidn2g0EFNfyCXR7/Xh3IAStgEUGFSQeu2S8cK2td2q/M8cJHyMKOZw==
X-Received: by 2002:a7b:c3d2:: with SMTP id t18mr14645165wmj.112.1605514690775; Mon, 16 Nov 2020 00:18:10 -0800 (PST)
Received: from [] (host194055148135.static.fidoka.tech. []) by smtp.gmail.com with ESMTPSA id u23sm19971749wmc.32.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 00:18:10 -0800 (PST)
From: Bruno Rijsman <brunorijsman@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EA703353-3154-4810-A4BA-D4F881960950"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 16 Nov 2020 09:18:08 +0100
Message-Id: <B4DCE709-39BC-40AA-9C92-25027A647498@gmail.com>
To: qirg@irtf.org
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/_fKq1wEwFmWVxiWIQzOhhz9Wb2E>
Subject: [Qirg] QIRG meeting minutes
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 08:18:18 -0000

Here are my notes for the QIRG meeting.

For the sake of clarity and brevity I have paraphrased many of the questions and answers. If I have misrepresented anything, let me know, and I will fix it.

-- Bruno


IETF 109 (online)
Quantum Internet Research Group (QIRG)
Monday 16 November

(1) Agenda bashing

(2) Status of the research group

- The USA department of energy announced the Quantum Internet blueprint: https://www.energy.gov/sites/prod/files/2020/07/f76/QuantumWkshpRpt20FINAL_Nav_0.pdf

- Rodney van Meter and Wojciech Kozlowski wrote blog post to promote QIRG working group: https://www.ietf.org/blog/quantum-internet/

- The principles draft is basically ready for last call; this will be discussed in this meeting.

- The use cases draft is almost ready for last call as well.

- There are three expired drafts: we need to determine whether to pick them up again (there is still interest in them):

- Proposal for next steps: 
  - Focus on education (e.g. talks)
  - We might shift to fewer IETF meetings and more (shorter) interim meetings
  - Keep working on drafts

(3) Presentation on "Measurement Device Independent (MDI) Quantum Key Distribution (QKD)" by Joshua Slater

- Slides at https://datatracker.ietf.org/meeting/109/materials/slides-109-qirg-mdi-qkd-quantum-internet-00

- Questions and comments:

- Bruno Rijsman: Can you explain why we need QKD (or PQC) to replace classical PKI in the first place? Josh Slater: The danger of Shor's algorithm breaking public key infrastructure (PKI) once we have sufficiently large quantum computers.

- Rodney van Meter: How long are the links that QuTech is installing in the 4 node quantum network? Josh Slater: Only the 1st fiber has been installed, it has 20 dB loss. The loss for the other 3 links is not yet known. Fibers are never straight-line and always have connection points that cause extra loss.

- Shota Nagayama: Do QKD networks have end-to-end conventional keys? Josh Slater: QKD networks securely generate end-to-end conventional keys.

- Shota Nagayama: Does QKD need trusted intermediate nodes? Josh Slater: The MDI QKD middle node does not need to be trusted [see also question from Kireeti Kompella later on].

- Philip Hallam-Baker: What about traffic analysis attacks? Josh Slater: An attacker can see when keys are generated, but cannot know the keys values or when the keys are actually used to encrypt.

(4) Status and recent updates on the use cases draft by Chonggang Wang

- "Applications and Use Cases for the Quantum Internet" draft at https://www.ietf.org/archive/id/draft-irtf-qirg-quantum-internet-use-cases-03.txt

- Presentation slides at https://datatracker.ietf.org/meeting/109/materials/slides-109-qirg-draft-irtf-qirg-quantum-internet-use-cases-01

- Questions and comments:

- Wojciech Kozlowski: I am still confused about quantum control plane versus data plane. It's clear for classical networks, but what does it mean for quantum networks? Chonggang Wang: Discusses table (figure 1) in the use cases draft. The data plane is actual user traffic, the control plane is not actual user traffic but facilitates user traffic exchange. The control traffic may be classical (e.g. setup protocols) or quantum (e.g. quantum ping).

- Michelle Victoria: Is the goal of the use cases document to guide the layman (rather than the quantum expert)? Chonggang Wang: There are two purposes. The document is intended for those who are interested to gain a high-level overview of applications before diving into the details. It is intended as starting point for later more detailed standards documents. Wojciech Kozlowski: It is intended for classical networking experts, not for complete laymen.

- Michelle Victoria: Should the draft include examples of benefits gained from distributed quantum computing? Chonggang Wang: Yes, it would be good to include some benefits in the next version. Wojciech Kozlowski: I provided similar feedback by e-mail. 

- Rodney van Meter: Suggestion to merge last two columns in figure 1 into a single column.

- Chonggang Wang: Is document ready for last call?  Wojciech Kozlowski + Rodney van Meter + Bruno Rijsman: Think it will be a very useful document but it needs at least one more iteration.

- Philip Hallam-Baker: The drafts and presentations should be careful not to equate transmission security with cryptography in general. QKD provides transmission security (encryption of data in flight); it does not provide a solution for encryption of data at rest. Presenting QKD as a general solution for Shor's attack on PKI is not appropriate. Not being able to protect data at rest for 30+ years is the scariest part of Shor. There are also other solutions, e.g. Kerberos is quantum resistant and Philip Hallam-Baker's work on "Threshold Key Infrastructure" (a generalization of PKI for data at rest). Rodney van Meter: Which specific parts of the draft need to be changed? Philip Hallam-Baker: The security section. 

- Philip Hallam-Baker: Also concerned about the traffic analysis point raised during the Q&A after Josh Slater's presentation.

(5) Status and recent updates on the principles draft, presented by Wojciech Kozlowski

- "Architectural Principles for a Quantum Internet" draft at https://www.ietf.org/archive/id/draft-irtf-qirg-principles-05.txt

- Presentation slides at https://datatracker.ietf.org/meeting/109/materials/slides-109-qirg-draft-irtf-qirg-principles-00

- Questions and comments:

- Wojciech Kozlowski: Is the draft ready for QIRG last call? Rodney van Meter: I submitted a list of comments in February; have all been addressed?  Wojciech Kozlowski: kept track of each individual issue on the mailing list and believes all have been addressed. Rodney van Meter: Has a discussion on 1st, 2nd, and 3rd generation networks been added? Wojciech Kozlowski: Yes, in the error management section (4.4.3). Rodney van Meter: Before last call, we need to read both drafts in parallel, and make sure they agree on terminology etc. Wojciech Kozlowski: we need to be alignment on the control plane in both drafts. Rodney van Meter: would like one more end-to-end parallel reading before signing off on last call (as author and chair). Wojciech Kozlowski: Let's keep question of last call for the mailing list.

- Rodney van Meter: how many people have read the draft recently (say version 4 or 5). The "show of hands tool" shows 12 raised hands, 6 not raised, 51 participants. 2 comments in the chat explicitly liked the draft and found it useful. Conclusion: decent number of people have had good read. Would like to initiate last call in the next couple of weeks, contingent on more round of reading.

(6) Open mike questions and discussion

Colin Perkins: Are prototyping and experimental implementations part of the next steps? Wojciech Kozlowski and Josh Slater: The work that is being done in QuTech on building the first quantum Internet has indeed taken inspiration from the QIRG work. The first network link is planned to be online in 2021. Next year it will be upgraded to include quantum repeaters. A recent paper on the quantum internet network layer protocol (https://arxiv.org/pdf/2010.02575.pdf) is specifically inspired on QIRG discussions. A paper on the quantum internet datalink layer (https://arxiv.org/abs/1903.09778) was already published earlier. There is a plan to publish the Quantum Network Experience (QNE) which will be a web-based front-end to run quantum distributed applications on the first prototype quantum network.

Rodney van Meter: Can you clarify whether the MDI QKD node needs to be trusted or not? I suppose it depends on how you define a "node"; in the context of quantum network architecture we went back and forth on the question whether a Bell state measurement middle-point should count as a separate node or as part of the link (the initial inclination was the latter). Bruno Rijsman: In the case of MDI QKD the middle node facilitates star shaped topologies, so it also includes (for example) MEMS cross-connects; it is more than just a BSM. Rodney van Meter: This is also applies to networks that create graph entangled states. Josh Slater: I feel that the midpoints / center nodes should be an active participant if it's acting to bring point-to-multi-point functionality. 
Wojciech Kozlowski: a useful analogy with classical networks may be to compare BSM midpoints with layer-2 local area networks, and true quantum repeaters / quantum routers with layer-3 wide area networks. Agrees that the midpoint can be an active element.

Kireeti Kompella: Can one cascade midpoints? Bruno Rijsman: For MDI QKD networks, if there is a single midpoint it can be untrusted. For multi-hop MDI QKD networks (a series of >= 2 midpoints) one needs either quantum repeaters or trusted midpoints.

Josh Slater: The Chinese QKD network is long chain of "super nodes" which are trusted, each midpoint has its own star network around it. The USA Quantum Xchange network between NY and New Jersey will have a similar topology. This supports the case for viewing midpoints as separate active nodes.

Joey Salazar: Does QKD provide anonymity? In other words, can the users that exchange keys be identified / tracked? Wojciech Kozlowski: No, QKD is currently not anonymous. Anonymity is difficult to guarantee for QKD, but may be possible for other applications.

Rodney van Meter: What is the process for finalizing the draft? The group and chairs conclude is work is done and submit it. The IRSG will review, check for conflicts with IETF, and provide  feedback. Most likely there will be comments. Then gets published as RFC.