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

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

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: Henrik Austad <[email-masked]>
Date: Wed, 13 Feb 2019 09:17:54 +0100

> Hi All,

Hi Ethan,

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

I must have missed that discussion - sorry!
(If this means that I'm covering old, settled points below, please just 
ignore my ramblings)

Question (relevant for my points below):

Do we plan to *encrypt* the header of the DetNet flows in transit, or will 
it be sufficient that the header is cryptographically signed?

Follow up; if we go with signing, will intermidate nodes have a need to 
update the DetNet hader, and if so, how do we solve the key-management 
problem for a per-flow set of signing keys to all relevant nodes?

-H

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

Since this covers more than 1 vector, perhaps it would be worthwhile to 
distinguish between confidentiality (encrypting the payload of the stream, 
preferrably in an end-to-end manner) and integrity (of the header itself 
using some sort of HMAC). As Maik pointed out in another email, we must 
make a point about crypto agility.

The payload itself should be end-to-end encrypted, the nodes should not 
have any need to inspect the payload itself. We can probably push the 
responsibility of this to the DetNet-application, the protocol should be 
data-agnostic.

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

Nitpick SHA-2 is a hashing algorithm, not a crypto-algorithm.

Also, Since SHA-2 is very similar to SHA-1 (which is considered broken),
SHA-3 was born. As with crypto agility, we should make a note about 
hash-function agility.

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

Not only TLS and IKE; this is pretty much how asymmetric crypto works. You 
create a symmetric key and you use asymmetrci crypto to share that secret 
between Alice and Bob.

Then you also re-generate the symmetric keys periodically. This is perhaps 
something we should make a not of, as that will add some additional cost, 
thus affecting the determinstic behaviour.

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

Hence the need to split the header from the payload, regenerate symmetric 
keys etc.

> Alternatively, asymmetric crypto can provide traffic origin verification 
> at every intermediate node.

Signature verification using public keys is a pretty deterministic 
operation I think, generate the hash, verify the signature. I need to dig 
through some books to be sure.

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

There are ways to avoid replay-attacks when you have secure hashes, but you 
must store some state on each node. Since each frame contains both a 
sequence-number and a stream-id, what we need are available to detect 
replays. This means that the header must either be transported in the 
clear, or that we can decrypt it in transit though.

-- 
Henrik Austad