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

Shames, Peter M (312B) peter.m.shames at jpl.nasa.gov
Fri Jul 6 17:19:38 UTC 2018


Dear Gippo, et al,

First of all, I'd like to suggest that we attempt, whenever possible, to reduce entropy rather than adding to it:

Entropy:
lack of order or predictability; gradual decline into disorder.

Second, in spite of the statement about adding entropy, I think you were close to the core of the issue, and in general I agree with your observations.  My suggestion to the Sec WG is that they adopt the new, more secure, 256 bit encryption algorithm as the recommended standard instead of 128 bit.  Security concerns are on-going and increasing, and leaving the recommendation at the lower level does a dis-service to the users of our standards.  We should be leading them to a better future, not holding them back.

That said, I also agree that leaving in the lower level of encryption, for backward compatibility, is appropriate.  My suggestion to the Sec WG is that they consider demoting this as "may use", along with a strongly worded NOTE to the effect of why it is bad idea.  That leaves the door open for missions to be compliant at the lower level, but informs them of the risk.  It's a sort of a "you can shoot yourself in the foot if you really feel you must." statement.

Lastly, as is the case with optional fields so many SLS standards, the specifics of the crypto algorithm chosen is now treated as a managed parameter.  That should continue because to do otherwise, such as inserting a "switch field" would require definition of a whole new protocol that includes that field.  There is no need to do this since the source of encrypted data and sink for encrypted data must coordinate keys in the first place.  Having them coordinate re which algorithm is in use is a trivial addition to that exchange.

Regards, Peter



From: SEA-SEC <sea-sec-bounces at mailman.ccsds.org> on behalf of Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Friday, July 6, 2018 at 2:38 AM
To: "Ignacio.Aguilar.Sanchez at esa.int" <Ignacio.Aguilar.Sanchez at esa.int>
Cc: Mehmet Adalier <madalier at antarateknik.com>, SEA-Sec <sea-sec at mailman.ccsds.org>, SEA-SEC <sea-sec-bounces at mailman.ccsds.org>, Howie Weiss <Howard.Weiss at parsons.com>
Subject: Re: [Sea-sec] Comment re: key sizes in Algorithm document // Meaning of backward compatibility

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
[cid:_1_1070C9FC1070C5EC0034E14BC12582C2]

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/dc98af38/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1156 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sea-sec/attachments/20180706/dc98af38/attachment.gif>


More information about the SEA-SEC mailing list