Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

[Brendan Moran <[e-mail]>]

We will take on board the majority of these comments.

WRT the PQC time horizon, quantum annealing attacks on RSA are dependent commercial quantum annealers.

The paper in nature shows the factorisation of 376,289 in 94 qubits. In fact, other researchers have factored 1,005,973 with only 89 qubits [1]. With this second algorithm, characterised as O(log^2(N)), RSA-768 would require 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits already. They have a historical average of doubling the number of qubits every two years. Based on this trajectory, they should be shipping a quantum computer that can break RSA-768 in approximately 2030 (log_2(147454/5640)) = 4.7 => 9.4 years. RSA-2048, then, would be broken between 2 and 4 years later, and RSA-4096 a mere 2 years after that.

This is a naive analysis. However, it is intended to show that a scalable general purpose quantum computer is not the only threat to current cryptographic techniques, that the time horizon is not long, and that urgent action is required to ensure that devices with long lifetimes account for EITHER cryptographic agility or quantum safety, preferably the latter, since quantum safe algorithms require much more data than classical asymmetric crypto and, therefore, require extra considerations, particularly when used in constrained IoT.

Obviously, the hole in this analysis is that RSA is not common in IoT. I have not yet found equivalent research that shows how a quantum annealer could attack ECDSA or EDDSA. I assume that there are research teams working on this. We should prepare ourselves for the potential of that particular revelation.

We have not gone into this detail in the architecture because it seems both orthogonal to the general discussion in the architecture, extremely time-sensitive, and extremely algorithm-sensitive. It will be an irrelevant prediction and analysis within a handful of years.

Best Regards,
Brendan

[1] https://link.springer.com/article/10.1007/s11433-018-9307-1


> On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-suit-architecture-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Does the XIP case mean that repeated firmware updates would have
> potential to cause undue wear on the fixed flash cells that hold the
> firmware image?  If so, this might be noted in the security
> considerations.
>
> I am not sure that I have fully digested Bob Briscoe's detailed review
> comments, but it seems like we may want to continue to reflect on which
> portions of the architecture will be optional to implement, and how we
> might indicate that in the document.
>
> I also made a pull request for some editorial nits at
> https://github.com/suit-wg/architecture/pull/15 .
>
> Section 1
>
>   otherwise difficult.  Firmware updates
>   for IoT devices are expected to work automatically, i.e. without user
>   involvement.  Conversely, IoT devices are expected to account for
>   user preferences and consent when scheduling updates.  Automatic
>
> I can't quite tell if the "Conversely" case is intending to refer to IoT
> or non-IoT devices.
>
>   The firmware update process has to ensure that
>
>   -  The firmware image is authenticated and integrity protected.
>      [...]
>
>   -  The firmware image can be confidentiality protected so that
>      attempts by an adversary to recover the plaintext binary can be
>      [...]
>
> Perhaps it's just because Bob Briscoe's comments are fresh in my mind,
> but there seems to be something of a mismatch across these texts -- we
> "have to ensure" that the firmware *is* authenticated and integrity
> protected, but only that the image *can be* confidentiality protected.
> Is it really the case that we can ensure that an update process *can be*
> confidentiality protected, or is the confidentiality requirement more of
> a requirement on the architecture than on actual deployment?
>
>   While the IETF standardization work has been focused on the manifest
>   format, a fully interoperable solution needs more than a standardized
>   manifest.  For example, protocols for transferring firmware images
>   and manifests to the device need to be available as well as the
>   status tracker functionality.  Devices also require a mechanism to
>   discover the status tracker(s) and/or firmware servers, for example
>   using pre-configured hostnames or [RFC6763] DNS-SD.  These building
>   blocks have been developed by various organizations under the
>   umbrella of an IoT device management solution.  The LwM2M protocol is
>   one IoT device management protocol.
>
> We might put some forward references to things we do cover (like status
> tracker(s)), and a reference for LwM2M as well.
>
> Section 3
>
>   Hence, the following components are necessary on a device for a
>   firmware update solution:
>   [...]
>   -  a status tracker.
>
> Earlier we said that having the status tracker on the device was fairly
> uncommon.
>
> Section 7
>
>   time horizon for quantum-accelerated key extraction.  The worst-case
>   estimate, at time of writing, for the time horizon to key extraction
>   with quantum acceleration is approximately 2030, based on current
>   research [quantum-factorization].
>
> I'm not sure that I see how the reference suports the "approximately
> 2030" statement.
>
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.