Bug 1573734

Summary: More fixes needed in crypto-policies for libreswan
Product: [Fedora] Fedora Reporter: Tomas Mraz <tmraz>
Component: crypto-policiesAssignee: Red Hat Crypto Team <crypto-team>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 28CC: crypto-team, lef, nmavrogi, pwouters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: crypto-policies-20180730-1.git9d9f21d Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-01 09:17:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Mraz 2018-05-02 07:36:43 UTC 
From Paul Wouters:
Looking at: https://gitlab.com/redhat-crypto/fedora-crypto-policies/commit/d941f7d504de5b5c6ac0c2fd3386079036e4aee5

DEFAULT:

The ike line parses fine. But it seems to miss aes256-sha2_256 for all DH group entries.

You then drop AES keysize on the same DH group, and only after that increase key size again for other DH groups.
I think it might make more sense to have all the 256bit entries come before all the 128bit entries ?

The esp line is:

        esp=aes_gcm256,aes256-sha2_512,aes256-sha1,aes128-sha1,aes128-sha2_256

I would still append aes256_sha2_256 at the end. It is the most likely to go wrong but it might still be configured by some.
It seems aes_gcm128 is missing. It should be the first 128bit choice.
It seem aes128-sha2_512 is missing. It might not make sense but people might still expect it.

FUTURE:

for ike line:

did you leave out aes256-sha2_256;dh20 on purpose? It seems logically missing. Similar for the other DH groups. I see sha2_256
is mostly missing here, so maybe it is only the first entry with sha2_256 that you forgot to remove?

LEGACY:

This seems to be missing DH5 completely, which is the most common used legacy value. People also try to use DH2, but I am
actually okay with even legacy no longer allowing it, as RFC 8247 made it MUST NOT. But without DH5 added, it won't work
with legacy systems. A lot of IKEv1 only old equipment does not support DH14.

I checked all the entries by placing them in a valid vpn connection and loaded/up'ed them to confirm there are no more parsing
errors in these entries.
Comment 1 Tomas Mraz 2018-05-02 07:45:07 UTC 
One thing to consider for DEFAULT and especially FUTURE policies is in which context the sha2_256 is used - for HMAC it can be combined with AES256 fine - there is no security strength mismatch. On the other hand for things like RSA signatures the actual security strength of the hash due to birthday paradox is half of the AES256 encryption.

In signatures you care about collision attacks but in HMACs you do not - there for forgery you need a second preimage attack which is not affected by birthday paradox.

I am not sure if use of hash in key derivation function is affected by birthday paradox (whether collision attack is useful there) or not.
Comment 2 Paul Wouters 2018-05-02 13:53:57 UTC 
Whether or not to use sha2_256 for ike and esp also depends on its prevalence. Currently it is very much in use (for ike more then esp due to the linux kernel bug with esp)

For FUTURE, we care a lot less because we are going to be defaulting to the ECP groups or X25519 / X448 anyway and sha2_256 will be downgraded then anyway.

That is why I propose to add them to the end of at least the DEFAULT.
Comment 3 Tomas Mraz 2018-05-18 11:41:50 UTC 
Paul, can you please look at https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/22/diffs - namely at the generated policies whether they address your concerns?
Comment 4 Paul Wouters 2018-05-18 16:02:33 UTC 
That looks okay. And it loads properly in my test and brings up a connection successfully.

Though it really makes me cry :P

I guess it would be easier if we add a new proposal-ike option that works more like ikev2, so the propsal could be rewritten as:

ike-prop=aes_gcm256,aes_gcm128,sha2_512,_sha2_256,_sha1,dh19,dh20,dh21,dh14,dh15,dh18;aes256,aes128,sha2_512,_sha2_256,_sha1,dh19,dh20,dh21,dh14,dh15,dh18;aes256,aes128

(we need to proposals, since one is with AEAD and one is with ENCR-INTEG, and those go into separate proposal structures in IKE.