Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Tue, 12 Feb 2019 07:22:34 +0000

Hello Ethan,

Only a few comments:

Execution times are essential for flow calculations.
On the other hand, to define bounded execution times is challenging.
And, does it make sense to use the boundary (value) for calculations?

Since this is a new standard, we should recommend agility of crypto algorithms in order to address quantum-safe crypto.
This especially impacts asymmetric algoritms.

Of course, there are implications with symmetric crypto, especially in terms of key management.
But I assume, this won’t be part of the text…

Cheers,
Maik

From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of "Grossman, Ethan A." <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 12. February 2019 at 06:25
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hi All,
I have consolidated the list discussion about the pros and cons of encryption algorithms into the Mitigation-Encryption section of the security draft (text of the section as it now reads is below). I would like the WG to review it before I publish it in a new version of the Security draft.
Thanks,
Ethan (as editor of the DetNet Security draft)
--------------------------------------------------------------------
5.    Security Threat Mitigation
5.4.         Encryption
Description
               DetNet flows can be forwarded in encrypted form.
Related attacks
Encryption can be used to mitigate recon attacks (Section 3.2.7). However, for the DetNet to give differentiated quality of service on a flow-by-flow basis, it must be able to identify the flows individually. This implies that in a recon attack the attacker may also be able to track individual flows to learn more about the system.
Encryption can also provide traffic origin verification, i.e. to verify that each packet in a DetNet flow is from a verified source, for example as part of ingress filtering.
5.4.1.     Encryption Considerations for DetNet
Any time spent on encryption and decryption processing (“crypto”) must be included in the flow latency calculations.. Thus, crypto algorithms used in a DetNet must have bounded execution times.
Some crypto algorithms are symmetric in encode/decode time (such as AES and SHA-2) and others are asymmetric (such as public key algorithms). There are advantages and disadvantages to the use of either type in a given DetNet context.
Asymmetrical crypto is typically not used in networks on a packet-by-packet basis due to its computational cost. For example, if only endpoint checks or checks at a small number of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of a secret symmetric crypto key; a successful check based on that key will provide traffic origin verification as long as the key is kept secret by the participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.
However, if we use secret symmetrical keys for this purpose we must give the key to all relays, which increases the probability of a secret key being leaked. Also, if any relay is compromised or misbehaving it may inject traffic into the flow.
Alternatively, asymmetric crypto can provide traffic origin verification at every intermediate node. For example, a DetNet flow can be associated with an (asymmetric) keypair, such that the private key is available to the source of the flow and the public key is distributed with the flow information, allowing verification at every node for every packet. However, this is more computationally expensive.
In either case, origin verification also requires replay detection mechanism as part of the security protocol to prevent an attacker from recording and resending traffic, e.g., as a denial of service attack on flow forwarding resources.

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 12 Feb 2019 19:10:42 +0000

Hi Maik,
Thanks for these comments.
Regarding "to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations?" - if I understand your question correctly, then yes, it does make sense, because end-to-end latency must be bounded so for any packet processing the worst case time must be used.
Regarding "we should recommend agility of crypto algorithms in order to address quantum-safe crypto" - I don't understand exactly the implication of this - can you suggest some changes to my text to incorporate this concept?
Thanks,
Ethan.
From: Maik Seewald (maseewal) <[email-masked]>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hello Ethan,

Only a few comments:

Of course, there are implications with symmetric crypto, especially in terms of key management.
But I assume, this won't be part of the text...

Cheers,
Maik

Hi All,
Any time spent on encryption and decryption processing ("crypto") must be included in the flow latency calculations.. Thus, crypto algorithms used in a DetNet must have bounded execution times.

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 12 Feb 2019 19:19:13 +0000

Maik,
Also I have paraphrased your earlier proposed additions to the Utilities use case text (as copied from the Use Cases draft for reference) in Appendix A of the Security draft. Here is the text I added, please let me know if you have any corrections or other changes.
          <t>Existing power automation security standards can inform network security. For example
            the NERC CIP (North American Electric Reliability Corporation Critical Infrastructure
            Protection) plan is a set of requirements designed to secure the assets required for
            operating North America's bulk electric system. Another standardized security control
            technique is Segmentation (zones and conduits including access control). </t>

          <t>The requirements in Industrial Automation and Control Systems (IACS) are quite similar,
            especially in new scenarios such as Industry 4.0/Digital Factory where workflows and
            protocols cross zones, segments, and entities. IEC 62443 (ISA99) defines security for
            IACS, typically for installations in other critical infrastructure such as oil and
            gas.</t>

          <t>Availability and integrity are the most important security objectives for the lower
            layers of such networks; confidentiality and privacy are relevant if customer or market
            data is involved, typically handled by higher layers.</t>

FYI All of Appendix A will probably be removed from the Security draft before publication, but during draft development we are keeping it there to provide a single reference point.

Thanks again for your input,
Ethan.

Hello Ethan,

Only a few comments:

Cheers,
Maik

Hi All,

---

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Wed, 13 Feb 2019 08:30:30 +0000

Hello Ethan,

It looks good!

Thanks.
Maik

From: "Grossman, Ethan A." <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 12. February 2019 at 20:19
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] DetNet Security Draft Proposed Text - Encryption

Maik,

From: Maik Seewald (maseewal) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hello Ethan,

Only a few comments:

Cheers,
Maik

Hi All,

---

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Wed, 13 Feb 2019 10:14:30 +0000

Hi Ethan,

Sorry for being that unspecific. Yes, the worst time must be used.
But this is very much hardware/implementation depending.

On encryption in general (and addressing Henrik’s response he sent minutes ago), this is typically an end-to-end requirement in many industries and is typically implemented in the upper layers: 4.5, 8, 9.
In many industries, that might use DetNet for WAN transport, it is not acceptable to have messages decrypted/encrypted on network nodes.

Regarding the agility, I had been very unspecific again. Reason, I don’t have a good answer ready to propose.
(1) It also depends on the depth we want to address crypto in this draft: prescribing algorithms vs. defining security objectives and controls (confidentiality/secrecy, integrity, …)?
And I have not yet mentioned the complex area of key management.

The comment reg agility is about the fact that quantum-based computing will break existing crypto much easier/faster, especially asymmetric algorithms.
In order to address this disruptive event, standards already addressing quantum-safe crypto in a very simple manner: recommending agility of crypto (e.g.: allowing endpoints to pick the best algorithms in a sequence; at least, not hard-coding things, very simple stuff but helpful).

Hope this is somehow useful…
But my response is basically boiling down to the question (1).

Cheers,
Maik

Date: Tuesday, 12. February 2019 at 20:10

Hi Maik,
Thanks for these comments.
Regarding “to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations?” – if I understand your question correctly, then yes, it does make sense, because end-to-end latency must be bounded so for any packet processing the worst case time must be used.
Regarding “we should recommend agility of crypto algorithms in order to address quantum-safe crypto” – I don’t understand exactly the implication of this – can you suggest some changes to my text to incorporate this concept?
Thanks,
Ethan.
From: Maik Seewald (maseewal) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hello Ethan,

Only a few comments:

Cheers,
Maik

Hi All,