Bug 1999868

Summary:	SSH and DEFAULT System Wide Crypto Policy
Product:	Red Hat Enterprise Linux 8	Reporter:	Ian <ian.murtaugh>
Component:	crypto-policies	Assignee:	Alexander Sosedkin <asosedki>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	8.4	CC:	pvrabec
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-09-01 17:10:26 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 Ian 2021-08-31 20:41:54 UTC

Description of problem:
The DEFAULT crypto policy does not consistently list the client side SSH KEX algorithms, host key algorithms, ciphers, and MACs in strength (preference) order.

How reproducible:
Always

Steps to Reproduce:
1. ssh -i somekey -vvv someuser
2. Review local client KEXINIT proposal to see the preference order specified by the client.

Actual results:
See additional info below.

Expected results:
See additional info below.

Additional info:
See /etc/crypto-policies/back-ends/openssh.config
See https://www.mankier.com/5/ssh_config under Ciphers, HostKeyAlgorithms, KEX Algorithms, MACs et cetera.

Here is an excerpt from an SSH session using -vvv option on a RHEL 8.4 client:

debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01,rsa-sha2-512-cert-v01,rsa-sha2-256-cert-v01,ssh-rsa-cert-v01,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm,hmac-sha1-etm,umac-128-etm,hmac-sha2-512-etm,hmac-sha2-256,hmac-sha1,umac-128,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm,hmac-sha1-etm,umac-128-etm,hmac-sha2-512-etm,hmac-sha2-256,hmac-sha1,umac-128,hmac-sha2-512

I am not an expert in all the of nuances of the various algorithms, ciphers, et cetera, but I would expect that the same algorithms using larger bit sizes would be specified (preferred) first.

EXAMPLES:

KEX: Currently these algorithms are listed in preference order as ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521.

host key: Currently these algorithms are listed in preference order as ecdsa-sha2-nistp256-cert-v01, ecdsa-sha2-nistp384-cert-v01, ecdsa-sha2-nistp521-cert-v01.

MACS: Currently these algorithms are listed in preference order as hmac-sha2-256-etm, hmac-sha2-512-etm.

Is there a reason that these are not specified in strength order?  Or is there something fundamental I am missing?

Version-Release number of selected component (if applicable):

Comment 1 Alexander Sosedkin 2021-09-01 11:15:10 UTC

> I am not an expert in all the of nuances of the various algorithms, ciphers, et cetera, but I would expect that the same algorithms using larger bit sizes would be specified (preferred) first.
>
> Is there a reason that these are not specified in strength order?  Or is there something fundamental I am missing?

I cannot answer the specifics either, but, in general, strength has to be balanced with performance (which doesn't even always scale monotonically with inverse strength).

With performance considerations in mind, I'd actually expect a baseline strength to be set, and order to be closer to "fastest for baseline strength; then stronger ones we need for forward compat; then weaker ones we'd need for backwards compat". Thus, what I see is less surprising for me than for you, and I would kindly decline your request in its generic form of reordering everything based on strength alone.

If you have more specific suggestions for reordering, ideally in form of "algorithm X is both more secure than Y and faster on my machine, but Y is prioritized for some reason, please promote X", I'd like to suggest you to open separate specific bugs both against RHEL and/or SSH upstream. Ideally we'd prefer for the change to be done upstream first.

Upstream priorities, for reference: https://github.com/openssh/openssh-portable/blob/cb37e2f0c0ca4fef844ed7edc5d0e3b7d0e83f6a/myproposal.h

Comment 2 Ian 2021-09-01 16:43:26 UTC

Thank you for the response and the information.  I will follow up with OpenSSH as needed.