[Sea-sec] UC Responses to Conditional Approvals of Security WG Documents

Thompson Paul B PBTHOMPSON at qinetiq.com
Mon Jul 23 08:19:44 UTC 2018


Just a thought (sorry for the delay) - are we making sure we're forwards compatible in the standard as well? I.e. can we make sure if we need to increase it in future we have a mechanism to allow us to do that?


Paul Thompson
Team Leader - Spaceflight E&E Engineering
pbthompson at QinetiQ.com<mailto:pbthompson at QinetiQ.com>

From: SEA-SEC [mailto:sea-sec-bounces at mailman.ccsds.org] On Behalf Of Ignacio.Aguilar.Sanchez at esa.int
Sent: 10 July 2018 10:09
To: Weiss, Howard
Cc: sea-sec at mailman.ccsds.org
Subject: Re: [Sea-sec] Responses to Conditional Approvals of Security WG Documents


I agree with the recommendation for the Glossary.

For the Algorithms pink sheet and with the purpose to better inform the readers for the selection of key length, I would add to Howie's proposal the following informative reference document in Annex B.

Daniel J. Bernstein (editor). Challenges in Authenticated Encryption. ECRYPT-CSA D1.1, Revision 1.05, 1 March 2017.

The document is written by some of the best cryptographers in the world and is maintained, that is, it will be updated whenever new results are available.
It could be cited in the note where users are discouraged to use smaller sizes.

I believe we have discussed this reference on a previous meeting.
Be aware that moving to 256-bit for AES key is currently considered likely to be an overkill (see chapter 1.5 for a consideration of Quantum computers and Grover's algorithm).
The editor and some members of the group are aware of the extreme particulars of space application. In the website that hosts the competition for a new authenticated encryption algorithm (https://competitions.cr.yp.to/caesar.html) they have specifically pointed to a contribution Daniel and I submitted in 2012 with that purpose (https://competitions.cr.yp.to/features.html). We wanted to establish a connection between cryptographic research and our future needs ('our' meaning all space agencies).

Kind regards,


[cid:image001.gif at 01D42266.49A4C250]

Ignacio Aguilar Sánchez
Communication Systems Engineer
Electrical Engineering Department

European Space Research and Technology Centre
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands
Tel. (31) 71 565 5695
Fax (31) 71 565 5418
Email: ignacio.aguilar.sanchez at esa.int

From:        "Weiss, Howard" <Howard.Weiss at parsons.com>
To:        "sea-sec at mailman.ccsds.org" <sea-sec at mailman.ccsds.org>
Date:        09/07/2018 19:19
Subject:        [Sea-sec] Responses to Conditional Approvals of Security WG        Documents
Sent by:        "SEA-SEC" <sea-sec-bounces at mailman.ccsds.org>



Two of our documents (Security Glossary and Algorithm Pink Sheets) have recently completed CESG polling.  The intent of the poll was to enable the documents release for Agency Review.

Both documents received "Approve with Conditions" from the MOIMS AD and D/AD.

For the Security Glossary, the "condition" received was:

Mario Merri (Approve with Conditions): Since this book it is merely
a glossary of terms, it is not clear to me why it has not been taken
this opportunity to silverise the original GB and put the terms in

For the Algorithms Pink Sheets (where the only changes were the increased key sizes) the condition received was:

Mario Merri (Approve with Conditions): The main change is the
strenghen of the authenticaltion keys. These have been increased,
thus making implementations that followed the previous CCSDS
recommentation not-compliant. Why has the document update not been
made in a backward-compatible manner, still strongly recommending
the new key lengths?

For the glossary, I would like to respond with the following:

  *   All terms in the SANA Glossary are defined in CCSDS documents; the definitions in those documents are the source of the SANA Glossary,
  *   The update to the Security Glossary is an actual update to the glossary; even if it were someday decided to retire the Security Glossary in favor of a SANA-only glossary, the update would still have to happen first,
  *   The change in document color is happening in conjunction with the update, but it is not what the CESG is being asked to approve (the CMC already approved the change in color),
  *   Therefore, the condition is actually not a condition that applies to the document update and should be withdrawn.

For the Algorithms pink sheets, I would like to respond with the following:

  *   The increased key sizes will be made a "shall" for future missions.  The smaller key sizes will remain in the document for backward compatibility as "may" specifications for use in older missions although we will include a note discouraging the use of the smaller key sizes as being potentially vulnerable to attack.

Comments?  Changes?  Other final suggestions?  Please respond quickly so we can expedite getting the documents into Agency review so we will receive RIDs in time to review at the Fall meetings.




Howard Weiss, CISSP

7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
443-494-9087 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com

Please consider the environment before printing this message

NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions._______________________________________________
SEA-SEC mailing list
SEA-SEC at mailman.ccsds.org

This message is sent for information and/or discussion purposes only.

It shall neither be binding nor construed as constituting a commitment for ESA.

It 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).

Thank you.

This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is 
addressed. If you are not the intended recipient of this email,
you must neither take any action based upon its contents, nor 
copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. QinetiQ may 
monitor email traffic data and also the content of email for 
the purposes of security. QinetiQ Limited (Registered in England
& Wales: Company Number: 3796233) Registered office: Cody Technology 
Park, Ively Road, Farnborough, Hampshire, GU14 0LX  http://www.qinetiq.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sec/attachments/20180723/c9bf5efe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1155 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sea-sec/attachments/20180723/c9bf5efe/attachment.gif>

More information about the SEA-SEC mailing list