Adding anima
[ Demi: next time, when you move a thread from one WG/RG to another one, please
include an explicit bread crumb where you came from, so folks in the new
mailing
list will know where to look for the origin of the thread. Luckily, IETF mail
archive search was good enough to allow me to find that this all originated
from CFRG thread "Current status of group-action based cryptography". ]
The IETF ANIMA WG standardized secure bootstrap mechanism BRSKI (RFC8995) and
a range of variations do hopefully resolve a good amount of the challenges
that John lists in his original email appended below.
Yes, the root problem of secure bootstrap "on-site" with minimum amount of
touch is for who or whatever does the enrolment to have some form of credential
to allow authentication for enrolment by the factory state device. We've
defined a generic, extensible artefact format for this problem called the
voucher (RFC8366, -bis currently in WG). It can go all the way down to
a bearer token, but preferred option is some pledge-manufacturer signed
owner certificate. Pledge of course has cert of its manufacturer.
Now, i just posted to CFRG the provocative claim that these bootstrap
protocols themselves likely do not need PG crypto because there is not
relevant PQ attack vector. Would love that challenge to get some answers -
either way.
But whether or not PK like ML-KEM is reasonable is not primarily a question
of bootstrap i think. It is primarily a question whether a device could
handle through its life cycle the added bitrate of PQ crypto exchanges.
After all: Why bootstrap devices into PQ crypto material if they can't use
it afterwards.
Of course there is always some type of constrained environment (nodes/devices)
that will have problem with anything you throw at it. But when it comes to
current IETF work focus, you probably want to go to DRIP for those with
the most challenging constraints (messaging to drones often likely via bluetooth
BLE in as few messages as possible).
When it comes to the most common building automation or industrial networking
environments as well as home networks, i think 802.15.4 derived mesh
networks like ZigBee/Thread are a good reference for low-end wireless.
These mesh networks typically deliver 256kbps raw or 20kbps end-to-end.
So i really don't see an issue to bootstrap into PQ. After enrolment,
these devices then typically only use symmetric keys.
I am not sure what the case of "millions of devices" would be that John
is referring to. But feel free to ask followup questions.
Cheers
Toerless
On Fri, Mar 06, 2026 at 03:09:44AM -0500, Demi Marie Obenour wrote:
> On 3/6/26 02:44, John Mattsson wrote:
> > Hi Demi,
> >
> > The operational aspects are probably better discussed in venues such
> > as IOTOPS. There are many practical challenges. Bootstrapping during
> > manufacturing is often too inflexible. Secure on-site bootstrapping
> > using a relay requires the device to support a second network
> > technology and requires the installer to carry special equipment and,
> > in remote locations, a portable Internet connection. Even when it
> > works, the the devices becomes significantly more expensive and
> > the installation process becomes slower and more complex, which
> > significantly increases the cost per installation, and deployments
> > may involve thousands or even millions of devices.
> >
> > From a security perspective, using trusted nodes is not
> > advisable. Many systems are deployed by independent installers,
> > and giving them access to secret keys significantly increases the
> > risk of compromise or leakage and may create legal issues. While
> > ephemeral key exchanges should ideally occur frequently, this
> > is unlikely to be feasible with ML-KEM. Even a single ML-KEM key
> > exchange for one device is challenging due to the limited uplink
> > and extremely constrained downlink capacity. If millions of devices
> > were to perform frequent ML-KEM exchanges, they would likely exceed
> > the network capacity. There is typically no “free” space to
> > piggyback ML-KEM fragments on existing messages. And while 1500
> > bytes is the additional overhead compared to ECC, implementing
> > secure and reliable fragmentation over many weeks with new messages
> > introduces a substantial amount of further overhead. More exact
> > estimates likely require similation.
>
> This actually leads to a separate problem: how are devices expected to
> authenticate the control node? This is easy if there is a cloud-based
> control plane, as the cloud server's authentication keys can be
> hard-coded. However, requiring a cloud service is undesirable from
> security, privacy, and reliability perspectives.
>
> Otherwise, the device somehow needs to obtain the authentication keys
> of its owner via an out of band mechanism, which could also be used
> for bootstrapping. The out of band mechanism could be as simple as
> the 1-Wire bus, which can be driven by a GPIO.
>
> An out of band mechanism is also useful for firmware updates, for
> which the radio network appears to be way too slow.
>
> Are CSIDH derivatives compact enough for frequent ephemeral key
> exchange? Their keys are still significantly longer than EC keys.
>
> As an aside, my understanding is that most OSS development mailing
> lists prefer avoiding top-posting. Are the norms different here?
>
> > On 2026-03-06, 04:52, "Demi Marie Obenour" <[email protected]> wrote:
> >
> > On 3/5/26 14:28, John Mattsson wrote:
> >> Demi Marie Obenour wrote:
> >>> Would it be possible to split the KEM over many messages, with forward
> >>> error correction used to ensure that the message eventually arrives?
> >>> The key exchange itself would take a very long time, but after setup
> >>> (which could be out of band) it would happen concurrently with traffic
> >>> already flowing through the network. Is sending 1500 bytes over a
> >>> matter of days a reasonable option?
> >>
> >> I think it is very good that you explicitly mention that in more
> >> constrained networks this could take days. Many people do not realize
> >> this, and it puts the “seconds of computation” discussion in a completely
> >> different light.
> >>
> >> An additional challenge in LPWAN networks is that downlink
> >> capacity is typically much smaller than uplink capacity. An
> >> installation process that takes several days would significantly
> >> increase operational costs, since failures would only be detected
> >> much later. While a single device might still be able to complete
> >> bootstrapping over the course of several days, deploying thousands
> >> of devices at scale could become problematic due to limited network
> >> capacity. In such cases, the overall installation process could
> >> stretch into weeks.
> >
> >
> > Would it be possible to perform bootstrapping out of band over an
> > unconstrained (or less-constrained) network? This should almost always
> > be possible because the devices need to be physically placed in their
> > intended locations. This means the devices need to be physically close
> > to a trusted party, and the key exchange could happen at this time.
> > Since the device only needs to communicate over a short distance,
> > it can use a high-speed network such as Bluetooth or Wi-Fi.
> >
> >
> > There are at least two ways this can be implemented:
> >
> >
> > 1. Each person deploying a device carries a relay node that has a
> > high-bandwidth uplink, such as cellular or LEO satellite service.
> > This is used to proxy traffic from the constrained device back to
> > its controller.
> >
> >
> > 2. Each person deploying a device carries a trusted node that records
> > the derived symmetric keys. After they return to base, this node
> > uploads the (encrypted) symmetric keys to the controller.
> >
> >
> > Subsequent key exchange is only necessary for forward secrecy, for
> > which https://signal.org/docs/specifications/mlkembraid/
> > <45acac64-721b-4904-9c71-686fcd0cef4e> can be used.
> > Thanks to Deirdre Connolly for mentioning this.
> >
> >
> >>> I wonder if they expect these networks to adapt to the changing
> >>> cryptographic requirements, rather than the other way around.
> >>
> >> I think government agencies sometimes have limited insight into how
> >> cryptography is used in different industries. One practical example I
> >> encountered was a government representative who had worked primarily
> >> with military systems and was very surprised that industry places
> >> significant emphasis on performance and cost.
> >>
> >> Another example is the suggestion to limit European industry to
> >> the ECCG ACM list. Such a restriction would be extremely costly for
> >> European industry and, in many cases, reduce security rather than
> >> improve it. More broadly, the focus on cryptographic algorithms is
> >> somewhat misplaced. Implementation bugs, misuse, and poor protocol
> >> design are often much greater sources of security problems than
> >> the algorithms themselves.
> >
> >
> > I agree. In particular, the low downlink capacity means that
> > OTA firmware updates are quite difficult, despite being absolutely
> > critical for security. Unless one is going to formally verify all
> > firmware that deals with untrusted inputs, there is likely to be at
> > least one remotely-exploitable vulnerability found.
> >
> >
> >>> From what very little I have read, it seems that the main reasons
> >>> these networks have such poor throughput are limited radio spectrum
> >>> and limited battery size. Both are ultimately under human control:
> >>> the first can be changed by regulators, and the second can be changed
> >>> by spending more on the product.
> >>
> >> Yes, but the total amount of spectrum is fixed and not under human
> >> control. There is very little unused spectrum in the sub-GHz bands
> >> suitable for LPWAN, and expanding spectrum for these networks would
> >> require reducing spectrum available to other services, something
> >> that is rarely practical.
> >>
> >> If bootstrapping occurs only once over the device’s 10-year
> >> lifetime, the impact on battery life is likely limited.
> >
> >
> > I think that key exchange should happen many times so that forward
> > secrecy is obtained, but the subsequent key exchanges are not
> > performance critical. OTA firmware updates are much harder.
> >> On 2026-03-05, 10:53, "Demi Marie Obenour" <[email protected]
> >> <4baf4eaa-f9cc-47e6-8f0c-efc0a170e02c>> wrote:
> >>
> >> On 3/5/26 02:42, John Mattsson wrote:
> >>> Hi,
> >>>
> >>> The large sizes of ML-KEM and the absence of NIKE have been identified as
> >>> significant hurdles for constrained radio systems. In secdispatch, Demi
> >>> Marie Obenour asked about the current status of CSIDH and
> >>> group-action–based cryptography. While I try to keep up with
> >>> developments, many members of CFRG undoubtedly have a far more
> >>> comprehensive understanding of the field.
> >>>
> >>> What is the current state of the art for quantum-resistant
> >>> group-action–based NIKEs, and when might this area be ready for
> >>> standardisation?
> >>>
> >>> Cheers,
> >>> John Preuß Mattsson
> >>>
> >>> From: John Mattsson <[email protected]
> >>> <c93fc91c-4b2e-459c-ae15-4ca2c8d822fb><mailto:[email protected]
> >>> <f6d1f6ee-4e4b-4fe7-9c22-131c935a96bf>>>
> >>> Date: Thursday, 5 March 2026 at 08:27
> >>> To: Demi Marie Obenour <[email protected]
> >>> <507852db-f462-45df-9523-3d67b80471e4><mailto:[email protected]
> >>> <7166d630-1a9a-43dd-86d5-cc14284455ea>>>, Phillip Hallam-Baker
> >>> <[email protected]
> >>> <d2de2b1c-53f4-4034-a1ab-07f4daa8a952><mailto:[email protected]
> >>> <9f129067-dd58-4a2f-92d8-ee6819e40fcd>>>, Carlos Aguilar Melchor
> >>> <[email protected]
> >>> <06e9e16f-15fc-473a-8d88-a5363bb5fb6b><mailto:[email protected]
> >>> <549ad24b-618a-4796-9b09-8df8c8f8f7e4>>>
> >>> Cc: Russ Housley <[email protected]
> >>> <78a594b5-efd5-4fc3-a69a-1270786e71db><mailto:[email protected]
> >>> <77cb8763-6075-4db8-9acc-45296c1cd16c>>>, IETF SecDispatch
> >>> <[email protected]
> >>> <d4317401-e51e-4f46-9c54-601dab18d5ff><mailto:[email protected]
> >>> <cd37fd42-6ccf-4a01-be4f-59cc0cf039ed>>>
> >>> Subject: [Secdispatch] Re: Topic request: Security protocols that
> >>> optimized for non-web and PQC
> >>>
> >>> Demi Marie Obenour wrote:
> >>>> What are some known improvements on CSIDH? Are further improvements
> >>>> believed possible?
> >>>
> >>> There has been extensive follow-up work on CSIDH and group-action
> >>> based cryptography since 2018. Research has focused on improving
> >>> software and hardware performance, strengthening implementation
> >>> security, refining parameter selection, and developing improved
> >>> cryptanalytic attacks. There are literally hundreds of papers.
> >>>> As far as I know, the general view is that further improvements are
> >>> very likely and that new attacks may emerge. I do not believe that
> >>> even the trade-offs of Kuperberg’s algorithm is yet sufficiently
> >>> well understood.
> >>
> >> Are any of these improvements likely to decrease the message sizes?
> >> Right now, it seems that quantum attacks keep increasing them.
> >>
> >>> Stephen Farrell wrote:
> >>>> It'd be useful if there were a draft with tables that showed the sizes
> >>>> with pq algs as well.
> >>>
> >>> The 600-byte absolute difference would still remain and still be
> >>> significant if ML-KEM were deployed. However, for many systems,
> >>> adding 1,500 bytes of overhead is simply not feasible. Many
> >>> constrained radio systems have no option but to continue using ECC,
> >>> or revert to symmetric-key-only solutions, with all the associated
> >>> limitations. A NIKE with much smaller public keys than ML-KEM would
> >>> therefore be a major advantage, even if it requires more computation.
> >> Would it be possible to split the KEM over many messages, with forward
> >> error correction used to ensure that the message eventually arrives?
> >> The key exchange itself would take a very long time, but after setup
> >> (which could be out of band) it would happen concurrently with traffic
> >> already flowing through the network. Is sending 1500 bytes over a
> >> matter of days a reasonable option?
> >>
> >>> I have asked both NIST and European agencies what they expect
> >>> constrained radio systems to do when they forbid ECC in 2030–2035
> >>> without getting any answers. I have also heard Scott asking NIST what
> >>> they plan as a replacement for the currently specified static-static
> >>> modes without gettting any answers.
> >>
> >> I wonder if they expect these networks to adapt to the changing
> >> cryptographic requirements, rather than the other way around. Nature
> >> does not owe us secure cryptography with small keys and messages.
> >> It could be that the only option that maintains security is to send
> >> more data.
> >>
> >> From what very little I have read, it seems that the main reasons
> >> these networks have such poor throughput are limited radio spectrum
> >> and limited battery size. Both are ultimately under human control:
> >> the first can be changed by regulators, and the second can be changed
> >> by spending more on the product. Neither helps cases like wildlife
> >> trackers, though, as those need to be small and light enough that
> >> they do not disturb the animal they are attached to.
> >>
> >>> At some point, I would like to see a ramp-on for NIKEs.
> >>
> >> I know it isn't an option for constrained devices, but SWOOSH
> >> is a (hopefully) fast option when bandwidth is not a concern.
> >>
> >>> Cheers,
> >>> John Preuß Mattsson
> >>>
> >>> On 2026-03-04, 21:57, "Demi Marie Obenour" <[email protected]
> >>> <6b8c2b80-d82a-4a21-992a-8b4e5c7a970b><mailto:[email protected]
> >>> <ccebc57f-a951-43a2-a23d-cdfa2830c883>>> wrote:
> >>>
> >>> On 3/4/26 05:04, John Mattsson wrote:
> >>>> Hi Demi,
> >>>>
> >>>> The LAKE WG is working on integrating PQC algorithms into EDHOC.
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-spm-lake-pqsuites/
> >>>> <eeccd51d-3824-4c2d-b3bd-eeaf4d2beb2c>
> >>>> This draft registers ML-KEM cipher suites for EDHOC, which can be used
> >>>> with both signature and PSK authentication. While EDHOC with ML-KEM-512
> >>>> is much larger than EDHOC with ECC, it is still significantly smaller
> >>>> than, for example, TLS 1.3 with X25519MLKEM768 or ML-KEM-512:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/09/
> >>>> <d82148bd-2a84-4a2b-81af-5bffa0aeaa8c>
> >>>>
> >>>> For signatures, NIST is making good progress. FN-DSA, MQ, and SQISign
> >>>> are all considerably smaller than ML-DSA:
> >>>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Nj1c9fWE0S8/m/p8_MPZ6lBAAJ
> >>>> <1579b886-25dd-4f54-865e-c058927885ce>
> >>>>
> >>>> CSIDH and its subsequent improvements do appear to be the only viable
> >>>> option for quantum-resistant key exchange with much smaller "key shares"
> >>>> than ML-KEM. Other lattice-based key exchange algorithms do not offer
> >>>> significant improvements and often comes with some disadvantages
> >>>> compared to ML-KEM. I wish NIST, CFRG, or an independent crypto
> >>>> competition would place more focus on isogeny-based NIKEs as a potential
> >>>> candidate for future standardization. They aren’t ready yet, but more
> >>>> focused efforts could help to make them ready. CSIDH would be a drop-in
> >>>> replacement for ECDH and EDHOC and could be used for both key exchange
> >>>> and authentication.
> >>>
> >>> What are some known improvements on CSIDH? Are further improvements
> >>> believed possible?
> >>>
> >>> Another significant concern with lattice-based and code-based KEMs is
> >>> that they are difficult to defend from physical side-channel attacks.
> >>> This is because one cannot validate ciphertexts without using the
> >>> secret key, so very powerful side-channel-assisted chosen-ciphertext
> >>> attacks are possible.
> >>>
> >>> I expect that there are cases where side channel resistance is much
> >>> more important than speed or message size. In these cases, I expect
> >>> Raccoon to be the obvious choice for signatures. For KEMs, would it
> >>> make sense to require that the sender provide a zero-knowledge proof
> >>> that the ciphertext was honestly generated? Or are there lattice-based
> >>> or code-based KEMs that are easy to protect from physical side-channel
> >>> attacks?
> >>> --
> >>> Sincerely,
> >>> Demi Marie Obenour (she/her/hers)
> >>>
> >>
> >>
> >> --
> >> Sincerely,
> >> Demi Marie Obenour (she/her/hers)
> >>
> >
> >
> >
> >
> > --
> > Sincerely,
> > Demi Marie Obenour (she/her/hers)
>
>
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
