[CESG] RE: Results of CESG Polls closing 14 August 2015

Biggerstaff, Craig (JSC-CD221)[LOCKHEED MARTIN CORP] craig.biggerstaff at nasa.gov
Thu Aug 27 23:16:39 UTC 2015

Dear ADs/DADs,

As the book editor of CCSDS 355.1-B-0 'Space Data Link Security Protocol', I have attached proposed text changes that, the WG believes, will resolve your CESG poll conditions.  Please review these changes and let me know if the changes answer your requirements.  Thank you.

Best regards,

Craig Biggerstaff

At 03:37 PM 8/17/2015, CCSDS Secretariat wrote:
>CESG E-Poll Identifier: CESG-P-2015-07-001 Approval to publish CCSDS
>355.0-B-1, Space Data Link Security Protocol (Blue Book, Issue 1)
>Results of CESG poll beginning 31 July 2015 and ending 14 August 2015:
>                  Abstain:  0 (0%)
>  Approve Unconditionally:  6 (66.67%) (Merri, Behal, Calzolari,
> Moury, Suess, Barton)
>  Approve with Conditions:  3 (33.33%) (Shames, Scott, Cola)
>  Disapprove with Comment:  0 (0%)
>Peter Shames (Approve with Conditions): We need this document to be
>published, and soon, but there are still a few inconsistencies that
>I believe should be fixed before that happens. There are marked in
>the attached text, but I will summarize them here:
>1) The document is missing a really good overview description and
>figure showing the relationship of the user provided transfer frame
>data field to the secured field. Such figures are in docs like CCSDS 232x0b.

What you are asking for was originally in the SDLS Red Book but was moved to the TC/TM/AOS Pink Books.  The WG would prefer to reference those books instead of duplicating the overview information.

>2) related to 1), the term "payload" is defined in sec 1.6, but it
>is then not used in any consistent way within the rest of the
>document. And the definition of the word "payload" is disjoint from
>other CCSDS usage. The word "package" or "user provided data" might be better.

The use of "Payload" in this document follows its common use within cryptography.  Its meaning within the context of this document has been defined in 1.8, and it is now capitalized as a proper name throughout.  The WG believes this will clear up any confusion.

>3) The Security Association Management Service, sec 3.4, reads like
>Green Book material, not Blue Book. There is not even an abstract
>service spec provided and as such it appears to be non-normative
>content. The related "Primitives" are not even sketched out, which
>makes this section look even more "unfinished".

The WG's consensus was that specifying only the required Security Association managed parameters was sufficient for 355.0, which the WG wanted to keep 'lightweight'.  The WG did originally consider a set of service primitives covering SA management, but decided that including them in the 355.0 core protocol would unduly constrain operations centers to a particular state model for operational key changes and recovery from spacecraft failures, where is not now any consensus to reverse agency-specific approaches.  Those subjects were deemed material for the Green Book or else for the SDLS Extended Procedures Blue Book.

>4) There is a repeated description of "Rollover of the sequence
>number could be used to signal the end of the acceptable lifetime of
>a cryptographic key", which sounds like specific guidance, but
>always appears in a NOTE. This might be better expressed in a real
>requirement as a "may".

The NOTEs have been modified to eliminate any guidance and to refer to the GB.

>Keith Scott (Approve with Conditions): I concur with Tomaso that a
>note stating the non-applicability of this specification to
>Proximity-2 communications would be quite helpful.
>Tomaso de Cola (Approve with Conditions): As the book relates to
>security implemented in the data link layer of CCSDS protocol stack,
>I would expect a note or comment in Section 1 to state that the
>scope of the book is limited to AOS, TM, and TC and does not address
>Proximity. Finding no mention of proximity leaves some uncertainty
>on the overall security implementation in SDLP.

A statement to this effect has been added to paragraph 2.1.

>Note for future book amendments, the green book CCSDS 350.0-G-2 (THE
>TO SECURE SYSTEMS ) will probably require some minor revision to
>reflect the changes provided in this blue book, once published.
>Total Respondents: 9
>No response was received from the following Area(s):
>PROPOSED SECRETARIAT ACTION:            Generate CMC poll after
>conditions have been addressed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 355x0b0_CESG_Approval with CESG comments dispositions 3.doc
Type: application/msword
Size: 849920 bytes
Desc: 355x0b0_CESG_Approval with CESG comments dispositions	3.doc
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150827/4db13cf9/attachment.doc>

More information about the CESG mailing list