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

[Hannes Tschofenig <[e-mail]>]

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

   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 remark below is addressed in PR#16:

"
   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?
"

The comment below is addressed in PR#17:

"
   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.
"

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

   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.
"

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.

"
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.
"

Ciao
Hannes

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Benjamin Kaduk
Sent: Thursday, November 19, 2020 12:10 PM
To: Brendan Moran <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail]; suit <[e-mail]>; The IESG <[e-mail]>; [e-mail]
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:
> 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.

_______________________________________________
Suit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/suit
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.