[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 20:45:29 UTC 2018


Peter, quickly two remarks. 

1) I think that the formulation (discussed longtime ago with Tom and more) in the tc coding book goes the right (stronger) stating that if you plan a new mission you SHALL use the longer key. 
2) the switch field is only possible if the first version planned for it (or has space by luck). So I mentioned but I never meant asking redesigning the protocol. 

Ciao

Gippo

Sent from my iPhone

> On 6. Jul 2018, at 19:19, Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov> wrote:
> 
> 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 
> <image001.gif>  
> 
> 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.

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/138e291a/attachment.html>


More information about the SEA-SEC mailing list