Re: Algorithms: who's at fault here?
Peter Gutmann <[email protected]> Fri, 26 Aug 2022 09:20:03 +0000
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <SY4PR01MB6251A8112B109EA2414B3376EE759@SY4PR01MB6251.ausprd01.prod.outlook.com> |
[email protected] on behalf of Simon Josefsson writes: >I think it makes sense to have at least two MUST algorithms for a security >protocol that are based on different mathematical properties. RSA-SHA256 and >25519-sha256 seems like popular and proven algorithms. I would strongly prefer ecdsa-sha2-nistp256 over the 25519 ones, the former is pretty widely supported while the latter is rarely available outside a few big implementations. More generally, it'd be good to have: diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 rsa-sha2-256 ecdsa-sha2-nistp256 aes128-cbc hmac-sha2-256 as MUSTS so you know you've got a basic set of parameters that will work. When it comes to the more obscure SSH implementations there's a neverending set of weirdo fashion-statement algorithms and mechanisms that people seem to want to enable while disabling any standard MTI ones. This is fine when the server is OpenSSH or the client is Putty, which implement everything in existence, but a real pain for interop when you don't implement every single algorithm ever dreamed up for SSH, including nonstandard semi-documented proprietary ones. For this reason my code has for several years now included special checks for, and error messages explaining, that the other side has enabled some oddball algorithm but none of the MTI ones and could they get the other side to fix their config. This level of custom coding and handling shouldn't be necessary just to get A to talk to B. Peter