Re: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04

Melchior Aelmans <melchior@aelmans.eu> Wed, 16 June 2021 20:55 UTC

Return-Path: <melchior@aelmans.eu>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365633A2670 for <qirg@ietfa.amsl.com>; Wed, 16 Jun 2021 13:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans.eu
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 B-79GJiQmO80 for <qirg@ietfa.amsl.com>; Wed, 16 Jun 2021 13:55:40 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 ACA8E3A266D for <qirg@irtf.org>; Wed, 16 Jun 2021 13:55:40 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id a127so3177464pfa.10 for <qirg@irtf.org>; Wed, 16 Jun 2021 13:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=q7okZVOS8Q38CAV/wjtyLqZyD71VGBd6TUjzqOJuWX0=; b=Cx2B4TwvEhlNudYBeUtmbgU+NcQY9AVzVU63lpkZ8fQZFBJK7mesmnFlQSOihI2pJe BN+ENbIKJFitg2XH50UHbM/x54VJvnlclBtwTglaZlw7+rrpOlZbB97EKjC5qEBY8qhk whx7esBOkHxqjWkQimj8X/1aBaNKW6r4T5R+gxFMnd3a0GlKCIVxmPno1mcKZSbeChEP Ktu7wLe6WkgN/1pWfoExJvtjuA/dq363WKcZBvam4Go5cP5cIcBVuVmRdUsDk6uiXEaL wo96VeynOkY9DVnTrebFVm7rwNIHA1Uod5ZlUEMn+0wBhpcUSTYdE47XyQRZ5ILWYJFI 1zdA==
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; bh=q7okZVOS8Q38CAV/wjtyLqZyD71VGBd6TUjzqOJuWX0=; b=cthvzvht06G53SpyqeMWNACyhH0VMjdoalpHAVvczp89pORdoYag6fjuQFyBFgRzFg Nyh+vcW7HV7YKPY3dZkHXooAIr5AAsaYyKAIP/1LAQq92XF0WOsdNrKqOde5rLFf4vzS DxfNRwEq4AUxWxC5VQoZixiNON2twm6g4ktFBIv6MxQ8in+DWy4MW4bBY6Z4rz6y5wje 6z3dY5q85H8RDvGIibezWpIKdeklnpofuig9vvMTuZ/dRQsln1iDDllmCKG9k0wln4Vz 0DBFOlF5SJU1F55UE5TtHnsfgXyM8QCIBM7IiJ9oNwuMBbeoiEjjbOwdelhFpU9JTwHf T3Qg==
X-Gm-Message-State: AOAM532WGzil/YIGXxvabf5Eh6nK6g49Y+WAcGIrR9zY7tgzfHUz5NJc 8Uzte+emgkk/AYH3sFFi6UgalcXsUq+lkdbsPN2S1A==
X-Google-Smtp-Source: ABdhPJzHShzmurLdM2Her5YENdZMMZ/3M9axXUSgtKRNBCZ4s7e/LRFewvt1w0Z5A70FpJSSslSn76/xMke4GO3e0p8=
X-Received: by 2002:a63:d511:: with SMTP id c17mr1480838pgg.219.1623876938976; Wed, 16 Jun 2021 13:55:38 -0700 (PDT)
MIME-Version: 1.0
References: <E2379064-70A3-47C7-8AE2-49682BDDE052@ericsson.com> <MN2PR10MB3485BC586EB476A3B78E22EDF87E9@MN2PR10MB3485.namprd10.prod.outlook.com> <BE5D5B52-6DD6-4B36-94D5-0B65FAA5D4CB@sfc.wide.ad.jp> <MN2PR10MB34852555401F25DA62249103F85B9@MN2PR10MB3485.namprd10.prod.outlook.com>
In-Reply-To: <MN2PR10MB34852555401F25DA62249103F85B9@MN2PR10MB3485.namprd10.prod.outlook.com>
From: Melchior Aelmans <melchior@aelmans.eu>
Date: Wed, 16 Jun 2021 22:55:28 +0200
Message-ID: <CALxNLBivSeeZ8UZSdR0mwK4fp_ECgzfkF5hVQ3--4VMj6EveuQ@mail.gmail.com>
To: draft-irtf-qirg-quantum-internet-use-cases@ietf.org, qirg@irtf.org
Content-Type: multipart/alternative; boundary="0000000000001b62ea05c4e85065"
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/Ute_6aY0j_jxSpSzcBHy6D_1qdo>
Subject: Re: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Quantum Internet 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: Wed, 16 Jun 2021 20:55:48 -0000

Dear co-authors, QIRG,

I have a couple of suggestions for the draft:

We might want to describe the classical internet supporting the Quantum
Internet. For example, current QKD is point-to-point where a dedicated
(dark)fiber is needed between 2 QKD boxes and a separate datachannel for
the QKD boxes to synchronise. This is very costly and resource intensive.
So might not be scalable or affordable. Some companies like Arqit and
Quantum Xchange are working on SDN like solutions to distribute quantum
generated keys acros a non-quantum link. The question is if it's then still
QKD, even when leveraging a post-quantum key distribution method it's not
quantum but math and so potentially breakable (at least eavesdropping is
possible without it being known). However this might be a
deployable solution so we should take it into consideration.

Also we might want to address 5G/self-driving cars use cases where timing
is critical. The exact timing is something quantum could provide perhaps?

Any ideas on this? I think it might be worth thinking about it and perhaps
address it in the draft.

Cheers,
Melchior

On Mon, May 3, 2021 at 3:08 PM Chonggang Wang <
Chonggang.Wang@interdigital.com> wrote:

> Hello Rodney,
>
>
>
> Thank you for the good suggestion.
>
>
>
> We replaced the Fitzi paper with the two references you suggested. For
> that, we also added the following sentence
>
>
>
> “A quantum aided Byzantine agreement on quantum repeater networks as
> proposed in [Taherkhani] includes optimization techniques to greatly reduce
> the quantum circuit depth and the number of qubits in each node.”
>
>
>
> Please refer to the new v06 of our document.
>
>
> https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/
>
>
>
> Best regards,
>
> Chonggang
>
>
>
> *From:* Rodney Van Meter <rdv@sfc.wide.ad.jp>
> *Sent:* Tuesday, March 30, 2021 6:43 AM
> *To:* Chonggang Wang <Chonggang.Wang@InterDigital.com>
> *Cc:* Rodney Van Meter <rdv@sfc.wide.ad.jp>; John Mattsson <john.mattsson=
> 40ericsson.com@dmarc.ietf.org>; qirg@irtf.org
> *Subject:* Re: [Qirg] Review of
> draft-irtf-qirg-quantum-internet-use-cases-04
>
>
>
> Chonggang,
>
>
>
> <list member hat on>
>
> One comment:
>
> The reference to the Fitzi paper on Byzantine agreement: I’ve read that
> paper, and I don’t recall all of the details, but my impression from it in
> (vague, fading) memory is that it doesn’t really solve the problem it’s
> claiming to solve, and certainly isn’t a full Byzantine agreement protocol,
> despite the title.  It’s more like “detectable broadcast”, and I’m not
> entirely sure how to use it.
>
>
>
> There is another quantum Byzantine agreement protocol by Hassidim &
> Ben-Or, which a visiting student to my group did some analysis of a few
> years ago.  (In fact, Amin might be on the list here?)  I think that’s a
> more useful approach, though we found that the implementation costs are
> high and I’m still not sure it’s useful in practice.
>
>
>
> @inproceedings{ben-or2005fast,
>
>   title={{Fast quantum Byzantine agreement}},
>
>   author={Ben-Or, M. and Hassidim, A.},
>
>   booktitle={Proceedings of the thirty-seventh annual ACM symposium on
> Theory of computing},
>
>   pages={481--485},
>
>   isbn={1581139608},
>
>   year={2005},
>
>   organization={ACM},
>
>   comment = {Should be citeable as an application of distributed QC.
>
>                   Uses secure multi-party communication protocol of
>
>                   Crepeau, Gottesman and Smith, known as QVSS.}
>
> }
>
>
>
> @article{taherkhani18:qba,
>
>   author={Mohammand Amin Taherkhani and Keivan Navi and Rodney Van{
> }Meter},
>
>   title={Resource-aware system architecture model for implementation of
> quantum aided Byzantine agreement on quantum repeater networks},
>
>   journal={Quantum Science and Technology},
>
>   volume={3},
>
>   number={1},
>
>   pages={014011},
>
>   url={http://stacks.iop.org/2058-9565/3/i=1/a=014011},
>
>   year={2018},
>
>   abstract={Quantum aided Byzantine agreement is an important distributed
> quantum algorithm with unique features in comparison to classical
> deterministic and randomized algorithms, requiring only a constant expected
> number of rounds in addition to giving a higher level of security. In this
> paper, we analyze details of the high level multi-party algorithm, and
> propose elements of the design for the quantum architecture and circuits
> required at each node to run the algorithm on a quantum repeater network
> (QRN). Our optimization techniques have reduced the quantum circuit depth
> by 44\% and the number of qubits in each node by 20\% for a minimum
> five-node setup compared to the design based on the standard arithmetic
> circuits. These improvements lead to a quantum system architecture with 160
> qubits per node, space-time product (an estimate of the required fidelity)
> {${KQ}\approx 1.3\times {10}^{5}$} per node and error threshold {$1.1\times
> {10}^{-6}$} for the total nodes in the network. The evaluation of the
> designed architecture shows that to execute the algorithm once on the
> minimum setup, we need to successfully distribute a total of 648 Bell pairs
> across the network, spread evenly between all pairs of nodes. This
> framework can be considered a starting point for establishing a road-map
> for light-weight demonstration of a distributed quantum application on
> QRNs.}
>
> }
>
>
>
>
>
> Rodney Van Meter
>
> rdv@sfc.wide.ad.jp
>
> Professor, Faculty of Environment and Information Studies, Keio
> University, Japan
>
>
>
> On Mar 30, 2021, at 8:19, Chonggang Wang <Chonggang.Wang@InterDigital.com>
> wrote:
>
>
>
> Hi John,
>
> Thank you very much for your detailed review and useful
> comments/questions. We have incorporated your feedback in the new version
> of this document, which was just uploaded as v05 (
> https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/
> )
>
> I also inserted some inline responses [CW] below to explain the changes we
> have made to v05. Please let us know if you have any further feedback.
>
> Best regards,
> Chonggang
>
> -----Original Message-----
> From: Qirg <qirg-bounces@irtf.org> On Behalf Of John Mattsson
> Sent: Thursday, March 11, 2021 6:37 PM
> To: qirg@irtf.org
> Subject: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04
>
>
>
> Review of draft-irtf-qirg-quantum-internet-use-cases-04
>
> Hi,
>
> I think this is a useful document. I do not think it is ready for RGLC yet
> but it is getting close.
>
> Cheers,
> John
>
>
> Comments:
>
>
> - Section 1
> "The connections between the various nodes in the Internet include Digital
> Subscriber Lines (DSLs), fiber optics, coax cable and wireless that include
> Bluetooth, WiFi, cellular (e.g., 3G, 4G, 5G), satellite, etc."
> This seems too focused on last mile Internet access.
> [CW] Rephased the sentences as the following one:
> “The connections between the various nodes in the Internet include
> backbone links (e.g., fiber optics), access links (e.g., WiFi, cellular
> wireless), etc.”
>
> - Section 1
> ”It is anticipated that the Quantum Internet will provide intrinsic
> benefits such as improved end-to-end and network security.”
> I would remove "anticipated" and "will". I don't think I have heard
> anybody working with security believed that QKD will provide much practical
> benefits. I mostly see it as something quantum network researchers do
> because they cannot do anything else yet. If you want to make such claims,
> I think you should ask CFRG or the security area in IETF.
> https://www.schneier.com/essays/archives/2008/10/quantum_cryptography.html
> https://www.schneier.com/blog/archives/2018/08/gchq_on_quantum.html
>
> https://www.nsa.gov/what-we-do/cybersecurity/quantum-key-distribution-qkd-and-quantum-cryptography-qc/
> [CW] Okay.  The whole sentence in question was deleted.  The rest of the
> document does not depend on this statement and since it is causing
> confusion it is best to just delete it.
>
> The document should also bring up denial of service risks and the
> requirement for trusted relays. These are areas where a Quantum Internet is
> expected to provide intrinsic security disadvantages.
> [CW] Trusted relays are discussed in multiple sections starting in section
> 5.1 onwards, so it is already well covered in the document.  On the point
> of denial of service risk, is there a specific reference that you could
> point us to?
>
> - Section 1
> "unique physical principles"
> Is unique the right word here?
> [CW] Changed the whole sentence to the following one:
> “The Quantum Internet will operate according to quantum physical
> principles such as quantum superposition and entanglement.”
>
> - Section 2
> The document does not seem to use any of the words. I don't know if an
> Informational IRTF docuement needs this section at all but if it does it
> should refer to RFC 8174 as well
> [CW] Okay.  We checked some other Informational IRTF RFCs and they do not
> have this section.  So, the section was deleted.
>
> - Section 3
> "i.e. fundamental unit of information in a classical computer"
> Bit is equally much a unit of informaiton in communication .
> [CW] Good point. Updated the definition below:
> “Bit - Binary Digit (i.e., fundamental unit of information in classical
> communications and classical computing)”
>
> - Section 3
> "from 50 to a few hundred qubits"
> Logical or physical qubits?
> [CW] Changed it to physical qubits.
>
> - Section 3
> "classical bits, or the measured state of qubits."
> They would still be classic bits
> [CW] Yes. Clarified the definition accordingly.
> “Packet - Formatted unit of multiple related bits. The bits contained in a
> packet may be classical bits, or the measured state of qubits in classical
> bits.”
>
> - Section 3
> "to securely distribute security keys from a sender to a receiver."
> I would more say that QKD let the two securely establish/agree on a key.
> [CW] Clarified the definition as suggested.
> “Quantum Key Distribution (QKD) - A method that leverages quantum
> mechanics such as no-cloning theorem to let two parties (e.g., a sender and
> a receiver) securely establish/agree on a key.”
>
> - Section 3
> OLD "The Quantum Internet will be merged into the Classical Internet to
> form a new Hybrid Internet"
> NEW "The Quantum Internet is expected to be merged into the Classical
> Internet to form a new Hybrid Internet"
> [CW] Thanks for the good suggestion and made the change accordingly.
>
> - Section 3
> "fundamental unit of information in a quantum computer"
> Qubit is equally much a unit of informaiton in communication .
> [CW] Good point. Updated the definition below:
> “Qubit - Quantum Bit (i.e., fundamental unit of information in quantum
> communication and quantum computing). ….”
>
> - Section 4.2.
> "Quantum cryptography applications - Refers to the use of quantum
> information technology to ensure secure communications"
> Just like classic cryptography, Quantum cryptography is much more than
> securing communication https://en.wikipedia.org/wiki/Quantum_cryptography
> [CW] Good point. Rephased the sentence below:
> “Quantum cryptography applications - Refers to the use of quantum
> information technology for cryptographic tasks such as quantum key
> distribution and quantum commitment.”
>
> - Section 4.2.
> "sensors or Internet of Things (IoT) devices"
> sensors are typically IoT devices.
> [CW] Removed “or Internet of Things (IoT) devices”.
>
> - Section 4.3.
> "to share a secret key"
> Probably good to explain to people that the key is a classic key.
> [CW] Agreed. Changed it to “… share a classical secret key …”.
>
> - Section 5.1
> "This results in a source quantum node A at Bank #1 to securely send a
> classic secret key to a destination quantum node B at Bank #2."
> I don't think that is a correct description of QKD. Maybe use "establish”
> or ”agree”
> [CW] Adopted “establish" and revised the original sentence below
> “This results in a source quantum node A at Bank #1 to securely establish
> a classical secret key with a destination quantum node B at Bank #2.”
>
> - Section 5.1
> "One requirement for this secure communication setup process is that it
> should not be vulnerable to any classical or quantum computing attack."
> Most of the attacks discussed on QKD has been more physical. It would be
> good if the document discussed other types of attacks then computing
> attacks. Wikipedia does e.g. mention the following: "The first attack that
> claimed to be able to eavesdrop the whole key [70] without leaving any
> trace was demonstrated in 2010. It was experimentally shown that the
> single-photon detectors in two commercial devices could be fully
> remote-controlled using specially tailored bright illumination. "
> [CW] Okay.  Added the following text:
> "One requirement for this secure communication setup process is that it
> should not be vulnerable to any classical or quantum computing attack.
> This can be realized using QKD [ETSI-QKD-Interfaces] which   has been
> mathematically proven to be unbreakable.  QKD can securely establish a
> secret key between two quantum nodes, without physically transmitting the
> key through the network and thus achieving the required security.  However,
> care must be taken to ensure that the QKD system is safe against physical
> attacks which can compromise the system. An example of a physical attack is
> when an attacker is able to surreptitiously inject additional light into
> the optical devices used in QKD to learn side information about the system
> such as the polarization.  Other specialized physical attacks against QKD
> have also been developed such as the phase-remapping attack, photon number
> splitting attack, and decoy state attack [Zhao]."
>
> - Section 5.1
> This section should mention authentication, which is a cornerstone in
> almost all security protocols.
> [CW] Added the following paragraph to Section 5.1
> “The post-processing procedure needs to be performed over an authenticated
> classical channel. In other words, the source quantum node and the
> destination quantum node need to authenticate the classical channel to make
> sure there is no eavesdroppers or man-in-the-middle attacks, according to
> certain authentication protocols such as [Kiktenko]. In [Kiktenko], the
> authenticity of the classical channel is checked at the very end of the
> post-processing procedure instead of doing it for each classical message
> exchanged between the quantum source node and the quantum destination node.”
>
> - Section 5.1
> "The source quantum node A transforms the secret key to qubits."
> I don't think the random bits should be called a "key" at this point
> [CW] Agreed and updated the sentence to the following one:
> “The source quantum node A transforms classical bits to qubits. Basically,
> for each classical bit, the source quantum node A randomly selects one out
> of two bases and uses the selected basis to prepare/generate a qubit for
> the classical bit.”
>
> - Section 6.1
> "a current 20-qubit machine"
> Would be good to inform the reader if these are physical or logical qubits.
> [CW] Changed it to “…a current 20-physical-qubit machine …”.
>
> - Security 9
> "because of the exponential increase of computing power with quantum
> computing"
> This seems like a press release from someone selling a quantum computer.
> I don’t think the claim is correct for integer factorization and discrete
> logarithm problem. The running time of GNFS is sub-exponetial and the
> running time of Shor is n^3 so the speedup should also be sub-exponential.
> Maybe correct for ECDLP.
> [CW] Okay.  Changed to “because of the increase in computing ability with
> quantum computing for certain classes of problems (e.g., prime
> factorization, optimizations).”  Also, re-worked the entire paragraph to
> make it clear that the threat/solution is specifically for Diffie-Hellman
> type public-key encryption systems.
>
> - Security 10
> ”Paradoxically, development of the Quantum Internet will also mitigate the
> threats posed by quantum computing attacks against public-key
> cryptosystems.”
> That is not true. QKD can only replace an unauthenticated Diffie-Hellman
> Exchange. The Quantum Internet will not do anything to mitigate the threats
> against digital signatures used in e.g. DNSSEC, TLS, IPsec, firmware
> updates, etc...
> [CW] Okay. Changed to be more precise: “Interestingly, development of the
> Quantum Internet will also mitigate the threats posed by quantum computing
> attacks against Diffie-Hellman based public-key encryption systems.”
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
> [Banner]
>
> [Banner]<
> https://www.interdigital.com/features/sustainability-in-a-wireless-world>
>
> Sustainability in a Wireless World: Research dedicated to understanding
> the impact of our technologies on the planet.<
> https://www.interdigital.com/features/sustainability-in-a-wireless-world>
> This e-mail is intended only for the use of the individual or entity to
> which it is addressed, and may contain information that is privileged,
> confidential and/or otherwise protected from disclosure to anyone other
> than its intended recipient. Unintended transmission shall not constitute
> waiver of any privilege or confidentiality obligation. If you received this
> communication in error, please do not review, copy or distribute it, notify
> me immediately by email, and delete the original message and any
> attachments. Unless expressly stated in this e-mail, nothing in this
> message or any attachment should be construed as a digital or electronic
> signature.
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
>