[Sls-sea-dls] SDLS WG Fall meeting

Tue Oct 13 05:11:42 EDT 2026

Dear Brian,

Many thanks for the comments! Some quick answers from my side below.

Kind regards,
Oana

From: SLS-SEA-DLS <sls-sea-dls-bounces at mailman.ccsds.org> on behalf of Sipos, Brian J. via SLS-SEA-DLS <sls-sea-dls at mailman.ccsds.org>
Date: Monday, 12 October 2026 at 23:41
To: Saba Bruno <bruno.saba at cnes.fr>; sls-sea-dls at mailman.ccsds.org <sls-sea-dls at mailman.ccsds.org>
Subject: Re: [Sls-sea-dls] SDLS WG Fall meeting

Bruno,
I will not be able to attend the upcoming CCSDS, but am very interested to see this kind of online AKE available for an SDLS control plane. I’m mostly involved in the SIS-DTN group but overlap in some topics with SDLS.

A few questions come to mind after browsing through the document:

  1.  There is mention of Noise frame patterns but I don’t see an explanation of which pattern this protocol makes use of. It seems like “KK” since each participating entity must be able to authenticate its peer on first message, but maybe not? Stating this explicitly in Section 2.4 would help a reader to understand the rest of the document, but I don’t see any mention of a specific “pattern” in there. Indeed, we can/should add a statement about relation to pqKK. InitHello carries skem (c_0, encapsulation to the Responder’s static key) and then e(c_1, the ephemeral pk_e). InitConf(c_4,c_5) and RespConf(c_6) are explicit key confirmation and sit outside the pattern. Both static keys are known in advance(->s, <-s pre-messages).

  2.  There is not any discussion of how to handle multiple public keys bound to a module identity, from either the sender’s side (which key to choose?) or the receiver’s side (can multiple authentication key pairs be enabled at any one time? Is there a mandatory “make before break” interval for compatibility and the goal of always available security?) This is currently under discussion and needs elaboration/confirmation.

  3.  A potential future binding of public keys to identities via a PKI leaves a lot to the reader. Is there any expectation of specific PKI technologies or existing identity binding mechanisms? If using X.509 under something like an IGCA, how would a SAN extension identify an entity? We have not discussed this in the WG so far but I believe we have to tackle it sooner or later. Currently the draft is PKI-agnostic. It requires only that the Module_ID <-> public key binding is authentic and integrity-protected.

  4.  I’m at a loss to connect the shared secret state from successful AKE operation to key material needed by SDLS. I suppose that Section 4.8 is meant to contain these kind of details eventually. It seems like there will need to be some method of “fan out” to derive many content keys for SDLS from a single security association shared secret. The concept has been discussed in the past in the CCSDS but it is not yet in the draft distributed by Bruno. The idea we discussed is as follows (was planning to include this info in Section 4.8 but still work in progress):

Each PQ-AKE-managed Security Association is organized as an SA family, identified by an SA Family ID. The family carries the static SA parameters; its keys are held in generations, one per successful handshake, numbered by the Handshake Number. At most two generations of a family exist at a time: the parent (HN_confirmed, committed) and the child (HN_pending, derived but not yet committed). One handshake creates the child generation of every family of the pair; activation by the flow brings the child into use direction by direction; commitment erases the parent, after which the child is the sole generation and becomes the parent of the next. Generation numbers increase strictly but not contiguously, since every handshake attempt consumes a Handshake Number whether or not it completes. The figure below illustrates the lifecycle for four families, considering in which state (i.e., from handshake and rekeying state machine in Section 4.4) the Initiator and Responder find themselves in. The parent is erased at the Responder on the first Forward Transfer Frame under the new keys and at the Initiator only on the first Return Transfer Frame on the new keys, so that between these two events the Responder holds one generation while the Initiator still holds two.

The 16-bit SPI of SDLS cannot name a PQ-AKE key: it would have to identify the two peers (the two Module_IDs), the family ID and the generation (Session ID). A Transfer Frame protected by a PQ-AKE-managed SA therefore carries the reserved SPI value 0xFFFF, and the key in use is identified by the tuple <PVN, SA Family ID, Initiator_ID, Responder_ID, Session ID>, the Session ID being the generation number.

[image.png]

So, practically, the proposal would be that when PQ-AKE is used, the SDLS Security Header will look  something like this (perhaps we need to add a PVN after the 16bit SPI. We are only using the “old” SPI, equal to value 0xFFFF to signal this is a new format of SDLS Security Header:
[image.png]

Thanks,
Brian S.

From: SLS-SEA-DLS <sls-sea-dls-bounces at mailman.ccsds.org> On Behalf Of Saba Bruno via SLS-SEA-DLS
Sent: Monday, October 12, 2026 8:30 AM
To: sls-sea-dls at mailman.ccsds.org
Subject: [EXT] [Sls-sea-dls] SDLS WG Fall meeting

APL external email warning: Verify sender sls-sea-dls-bounces at mailman.ccsds.org<mailto:sls-sea-dls-bounces at mailman.ccsds.org> before clicking links or attachments

Dear SDLS Working Group members,

Next week we will have our technical meeting in Matera, Italy.

Please find attached the draft standard for comments. I know it’s a bit late, please accept my apologies…

Oana did a tremendous work, all comments are welcome before our meeting.

Looking forward to a fruitful meeting,

Best regards,

Bruno Saba
CNES
SDLS WG Chairman

Bruno SABA
Sous-direction DTN/TVO : Technique & Numérique / Techniques Véhicules Orbitaux
Service ET                     : Electronique Numérique & Traitements Bord

18, Avenue Edouard Belin, 31401 TOULOUSE Cedex 9
Tél : +33 (0)5 61 28 28 76
cnes.fr<https://cnes.fr/fr/>

[cid:image001.jpg at 01DD5A30.479F5FA0]

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20261013/e2cae0de/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 65058 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20261013/e2cae0de/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33825 bytes
Desc: image.png
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20261013/e2cae0de/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 135348 bytes
Desc: image.png
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20261013/e2cae0de/attachment-0003.png>