Add a way to disable or report weak ciphers, hashes and keys.

[ni4]

Description

While this is certainly needed, there is no good way to report signature or encryption as weak for now, or to disable certain hashes and ciphers (like MD5, IDEA).

However, we still need to support these to be able to verify/decrypt old messages.

I see the following way of implementing this:

• adding FFI functions rnp_add_weak_cipher("IDEA"), rnp_add_weak_hash("MD5"), rnp_add_weak_key("DSA", 512), etc.
• adding FFI function like rnp_signature_get_weaknesses(sig, char **weak) which will report weak elements (hash, key, algorithm).
• adding special signature verification result RNP_SIGNATURE_WEAK
• adding function like rnp_op_verify_get_weaknesses(op, char **weak).

Some of weak cases could be predefined, like usage of non-MDC encrypted data, non-iterated S2K, whatever else.

[ni4]

@kaie @dewyatt @ronaldtse @rrrooommmaaa @antonsviridenko You are welcome for discussion here!

[nwalfield]

This is indeed a complicated topic. We address this issue in Sequoia using customizable policy objects. A policy object includes a number of callbacks that are invoked when evaluating a signature, encryption container, etc. We provide a default easily customizable, StandardPolicy.

Our approach means that there isn't a global policy (global variables are bad!). But, perhaps more importantly, it means that it is possible to actually evaluate critical notations before they are used. For instance, when checking a self-signature, if there are any critical notations, the self signature must to be revoked/ignored if the application doesn't understand the notations. It is not sufficient for the application to indicate what notations is understands, because then it is basically impossible for the application to implement custom security policies using the notations (the application needs to examine the notations because the signature is used).

I strongly encourage you to copy our design.

[dkg]

See also this thunderbird report about how they are currently working around the lack of this functionality.

[antonsviridenko]

How many things will break if we make everything strict by default? I.e. no weak ciphers and algos accepted in input files, no weak output produced?

We can implement something like security levels in OpenSSL, see https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_get_security_level.html for more details

[kaie]

A level may be insufficient. It may be an application decision, or even a user configuration decision, which ciphers are considered weak or not acceptable. For example, RNP supports the SM* algorithms. A user inside China might prefer to have them enabled, while a person outside China might prefer to disable them.

[ni4]

Currently working idea is to mark definitely weak hashes/ciphers/small key size by returning some specific error code (like RNP_ERROR_WEAK_CRYPTO), so "simple" implementation will return an error, more complicated - tell the user "signature is valid, but uses weak cryptography", and add some compilation switches to disable certain algorithms.

[dkg]

@ni4 wrote:

Currently working idea is to mark definitely weak hashes/ciphers/small key size by returning some specific error code (like RNP_ERROR_WEAK_CRYPTO), so "simple" implementation will return an error, more complicated - tell the user "signature is valid, but uses weak cryptography", and add some compilation switches to disable certain algorithms.

It looks like Thunderbird is expecting some sort of API to disable specific features at runtime. @kaie, would @ni4's proposal above be sufficient?

[ronaldtse]

@dkg the latest proposal is located here: https://github.com/rnpgp/rnp/pull/1524#issuecomment-956019966 .

@kaie could you let us know if it satisfies the needs?

[ni4]

@dkg the latest proposal is located here: #1524 (comment) .

In addition, we'll have some compiler switches to disable certain algorithms completely from the compilation (already have few of them for OpenSSL backend).

[dkg]

I don't know that compiler switches will be useful for thunderbird's purpose, if we're talking about thunderbird using the system-installed librnp -- if that's the case, then thunderbird won't get to choose compile-time switches, right?

I raise this because i'd prefer that on debian, thunderbird uses the system librnp, due to debian policy of avoiding embedded code copies.

[ni4]

I don't know that compiler switches will be useful for thunderbird's purpose, if we're talking about thunderbird using the system-installed librnp -- if that's the case, then thunderbird won't get to choose compile-time switches, right?

Yeah, compile switches will not work for TB purpose (for that purpose we'll have security profiles). Currently it is to be able to disable certain features on systems where backend doesn't support them. Another purpose could to disable some algorithm completely due to security reasons, when compatibility with old implementations or data is not required.

[ronaldtse]

Great comments here and we can probably consider the availability of algorithms in this order:

• availability or the lack thereof in a backend/system
• enabled or disabled in compilation
• accepted or rejected by runtime configuration

We will need to support these cases.