[Sea-sec] Comment re: key sizes in Algorithm document // Meaning of backward compatibility

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Fri Jul 6 09:37:35 UTC 2018


Ignacio,
        there are different meanings/approaches for the backward 
compatibility.
Sometimes (often) backward compatibility is allowed by including in the 
message a switch field (e.g. one or more bits) indication the version 
applied to that message, in other case there is managed parameter telling 
to that implementation whether the message will be compliant to formatting 
1 or formatting 2. .
In this way the receiving side can decide which kind of processing shall 
be applied to that message.

The usage of a switch field in-line with the message is particularly 
efficient for  space-to-ground links as usually ground equipment implement 
all (or at least many) allowed options.
Conversely, spacecraft rarely implement more the unique selected option 
for obvious reasons. 

So to reply specifically to your questions:
1)  For instance is Mario implying that future implementations with the 
recommended larger sizes are also capable to support smaller sizes, if 
necessary, so that everybody is compliant? 
Look at my points above. Somebody may need to be compliant (not 
everybody).

2) We know that most spacecraft  implementations do not allow for 
in-flight reprogramming of cryptographic functions to support different 
key sizes (longer or shorter) or new algorithms. This means that any 
recommendation for a different key size (larger in this case) makes those 
systems not compliant. 
This depend from what you write in your standard. If you take away the old 
specification, YES any old implementation is not compliant. You you keep 
in your standard "somehow" version 1 and version 2 and old implementation 
is only complaint to version 1.

3) So why should older implementations need to be compliant with a future 
standard? 
Because implementers (agencies, industry, etc.) make investments and if 
you rule out an old implementation tout court  this creates problems.

4) Aren't future standards written for future systems? 
Not only.
Moreover the concept of future is somehow vague.
You may have a mission that will fly in two years but for which decisions 
are already taken.
Is that one a future mission? IMO NO. It is not because it is already on 
going even if not flying yet.
This is why when debating about PLOP-1 and PLOP-2 the best formulation we 
found was "shall be used for missions whose planning begins after 
September 2010"
Moreover a flying mission may need to be supported for a number of future 
years (and this why why we wrote "may still be used in ground equipment 
for the support of legacy missions")


All in all the point is that ruling out a previous version is a risky 
decision. For this reason sometimes it is better to keep into standards 
both versions with clear remarks, using if possible a switch field or 
highlighting the need for a managed parameter and for sure making clear 
effects and recommendations.

I hope this was adding entropy to the discussion.

Regards

Gian Paolo

PS Note that I did not go back checking the Algorithms document and 
therefore some of my statements may be inaccurate but general.




From:   Ignacio.Aguilar.Sanchez at esa.int
To:     "Weiss, Howard" <Howard.Weiss at parsons.com>
Cc:     Mehmet Adalier <madalier at antarateknik.com>, 
"sea-sec at mailman.ccsds.org" <sea-sec at mailman.ccsds.org>
Date:   06/07/2018 09:55
Subject:        Re: [Sea-sec] Comment re: key sizes in Algorithm document
Sent by:        "SEA-SEC" <sea-sec-bounces at mailman.ccsds.org>



Howie et al., 

I have seen Charles', Mehmet's and Daniel's contributions to your e-mail. 

I would like to understand first what Mario means with backwards 
compatibility and what it could actually mean in this context (does it 
make sense at all?). 
For instance is Mario implying that future implementations with the 
recommended larger sizes are also capable to support smaller sizes, if 
necessary, so that everybody is compliant? 
We know that most spacecraft  implementations do not allow for in-flight 
reprogramming of cryptographic functions to support different key sizes 
(longer or shorter) or new algorithms. This means that any recommendation 
for a different key size (larger in this case) makes those systems not 
compliant. 
So why should older implementations need to be compliant with a future 
standard? 
Aren't future standards written for future systems? 
Maybe I am missing something but frankly, I am a bit at a loss with the 
comment. 

Kind regards, 

Ignacio 
 

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
www.esa.int 



From:        "Weiss, Howard" <Howard.Weiss at parsons.com> 
To:        "sea-sec at mailman.ccsds.org" <sea-sec at mailman.ccsds.org> 
Date:        05/07/2018 19:38 
Subject:        [Sea-sec] Comment re: key sizes in Algorithm document 
Sent by:        "SEA-SEC" <sea-sec-bounces at mailman.ccsds.org> 



We currently have two documents in CESG polling for Agency Review. 

On the Algorithms document, we have increased the minimum key sizes. 
However we have a comment from Mario Merri (ESA): 

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

Peter Shames suggested that we make the larger key size a "shall" but 
allow the smaller key sizes as "may" with a note strongly discouraging the 
smaller key sizes. This would satisfy Mario's backward compatibility 
issue.   

Any comments?  Any disagreements?  Any other suggestions? 

Thanks. 

regards 

howie 


Howard Weiss, CISSP

PARSONS, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
443-494-9087 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com
www.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
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sec


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.

_______________________________________________
SEA-SEC mailing list
SEA-SEC at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sec



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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sec/attachments/20180706/83edba6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1155 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sec/attachments/20180706/83edba6c/attachment.gif>


More information about the SEA-SEC mailing list