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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 05 Nov 2020 01:38:54 -0800

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.

---

From: Brendan Moran <[email-masked]>
Date: Wed, 18 Nov 2020 22:05:44 +0000

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 <[email-masked]> wrote:
>

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Nov 2020 03:10:24 -0800

Hi Brendan,

Thanks for the extra reference and discussion about the timescale estimates
for quantum computers and integer factorization.  (And for accepting most
of my other comments.)  I see now how the factorization-by-annealing
reference was intended to be used, and had not been paying close enough
attention to know the 5640-qbit and doubling-every-two-years numbers for
D-Wave.

If I was going to suggest a change to the text, it would be quite small,
perhaps something like "based on current research [quantum-factorization]
and the trend in quantum annealing capacity".

Thanks again,

Ben

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Nov 2020 05:34:21 +0100

Benjamin, *:

I do not think that the simple extension of the current text explanation
to include "and the trend in quantum annealing capacity" would help:

>From reading Brendans text below and doing a quick search through
[quantum-factorization], it looks to me as if the conclusion
currently written into the draft "... approximately 2030 ..." is an original
research conclusion by Brendan et.al. and can not be directly found in
[quantum-factorization]. The actual reference for the conclusion is
the text below from Brendan, and if the 2030 prediction is to be kept in the
text then readers should be made aware of this original research.

I would obviously like to see the three paragraphs from Brendan put
somewhere into the draft (appendix or the like), but if the authors worry about length, then
they could simply put a reference to Brendans email into the draft
(aka: see [https://mailarchive.ietf.org/arch/msg/suit/Ao2OlGo0yhjLncVftTLAJ2jjw2E/]) 

Cheers
    Toerless

On Thu, Nov 19, 2020 at 03:10:24AM -0800, Benjamin Kaduk wrote:
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

-- 
---
[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Nov 2020 06:27:32 +0000

Hi Ben

Thanks for your review and for your PR with the proposed changes.

I have created PRs to address some of your remarks:
https://github.com/suit-wg/architecture/pull/16
https://github.com/suit-wg/architecture/pull/17

I have addressed the remark below in PR #16:

"
Section 1

"

The remark below is addressed in PR#16:

"

"

The comment below is addressed in PR#17:

"

"

I did not make changes regarding this comment because I couldn't find text that claimed that the status tracker on the device is uncommon.

"
Section 3

"

The issue about post-quantum crypto is being discussed separately.

Regarding the comment below I still have to think about how to best address it.
Flash memory wears out but there are different flash memories and there are flash controllers trying to prevent uneven wear-out.
I have to think about what the draft should discuss regarding the implications of execute in place (XIP) with respect to the wear of flash memory.

"
"

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Thursday, November 19, 2020 12:10 PM
To: Brendan Moran <[email-masked]>
Cc: Russ Housley <[email-masked]>; [email-masked]; suit <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

Hi Brendan,

Thanks for the extra reference and discussion about the timescale estimates for quantum computers and integer factorization.  (And for accepting most of my other comments.)  I see now how the factorization-by-annealing reference was intended to be used, and had not been paying close enough attention to know the 5640-qbit and doubling-every-two-years numbers for D-Wave.

If I was going to suggest a change to the text, it would be quite small, perhaps something like "based on current research [quantum-factorization] and the trend in quantum annealing capacity".

Thanks again,

Ben

On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote:
> > 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
> > 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 can't quite tell if the "Conversely" case is intending to refer to
> > IoT or non-IoT devices.
> >
> > 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?
> >
> > We might put some forward references to things we do cover (like
> > status tracker(s)), and a reference for LwM2M as well.
> >
> > Section 3
> >
> > Earlier we said that having the status tracker on the device was
> > fairly uncommon.
> >
> > Section 7
> >

---

From: Brendan Moran <[email-masked]>
Date: Fri, 20 Nov 2020 17:04:41 +0000

Hi Toerless,

In fact, this is not original research by me. You can find an article that details this analysis here: https://www.linkedin.com/pulse/breaking-rsa-encryption-update-state-of-the-art-andreas-baumhof

I checked the references and I think that the conclusions are sound.

Brendan

> On 20 Nov 2020, at 04:34, Toerless Eckert <[email-masked]> wrote:
>
> Benjamin, *:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 21 Nov 2020 00:42:21 -0800

Hi Hannes,

The PRs look good; thanks.  Following up inline on the bit that was unclear...

> Earlier we said that having the status tracker on the device was fairly

I suspect I was thinking about this text in Section 2.3:

   -  Firmware Server: The firmware server stores firmware images and
      manifests and distributes them to IoT devices.  Some deployments
      may require a store-and-forward concept, which requires storing
      the firmware images/manifests on more than one entity before
      they reach the device.  There is typically some interaction
      between the firmware server and the status tracker and these two
      entities are often physically separated on different devices for
      scalability reasons.

Specifically "often physically separated on different devices".

> I have to think about what the draft should discuss regarding the implications of execute in place (XIP) with respect to the wear of flash memory.

It's quite possible that "what the draft should discuss" ends up being
"nothing", especially if the same flash chips are used for other operations
that incure significantly more frequent writes.  Thank you for thinking
about it, though!

Thanks as well for the updates,

Ben