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

["Grossman, Ethan A." <[e-mail]>]

Hi Henrik,
Oops, my turn to be sorry - until now I missed your notes that were inline with my text below. I just went through them and put my comments inline below (prefixed EAG:). I also noted the resulting changes I will make in my text for this update to the DetNet Security draft. Some points are certainly worth further discussion; for now I am limiting my scope of revision to the current proposed section text. Others on the list are encouraged to add their thoughts to this thread, and I can incorporate them into the next revision. 
Thanks again for your contribution,
Ethan.

-----Original Message-----
From: Henrik Austad <[e-mail]> 
Sent: Wednesday, February 13, 2019 12:18 AM
To: Grossman, Ethan A. <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

On Tue, Feb 12, 2019 at 05:25:40AM +0000, Grossman, Ethan A. wrote:
> 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?

EAG: My understanding is that this would depend on the requirements of the use case, i.e. the design/implementation of a given DetNet. That is, some use cases that require very high levels of security might want to encrypt the header, and be willing to accept the performance hit. Others might require minimum latency and not require that the headers be encrypted, or perhaps even signed. However I think this would make a good discussion for the list to see if there is anything we can agree on that would apply to all DetNets. Having said that, you already sent this email to the list and we got no further discussion on the topic, but maybe this will revive the discussion. 

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

EAG: Referring back to my comment above, I hope that this level of specificity can be left as an exercise to the DetNet designer. If you are saying that this is something that has to be resolved at the DetNet Architecture level, please let us know so that we can address it. 

-H

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

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.

EAG: I am trying hard to limit the scope of the DetNet Security draft to security considerations related specifically to time-sensitive aspects of DetNet. It seems to me that the discussion about confidentially vs integrity is a very good point, as is the point about crypto-agility, but I'm hoping that these are generic enough to be "considered to be covered elsewhere". Do you agree?  

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

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.

EAG: OK I will remove the reference to SHA-2, it isn't necessary to have a second example there. 

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

EAG: OK, I suppose I can leave my existing text as it is. 

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.

EAG: This is a highly relevant point. I added the following:  "If crypto keys are to be regenerated over the duration of the flow then the time required to accomplish this must be accounted for in the latency calculations."

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

EAG: Right. Again I think this is a generic consideration? 

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

EAG: I don't think we want to make any particular claims about specific algorithms or processes here, just a general comparison between technologies. 

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

EAG: I believe that this is covered by the phrase "also requires replay detection" - your comments are about how to implement such a mechanism, right? 

-- 
Henrik Austad