Is ...WITH_NULL... supported?

[FlorianMueller87]

Hello,

I try to answer to a DTLS client Hello with the cispher TLS_PSK_WITH_NULL_SHA256.
The exception "Can't agree on a ciphersuite with client" will thrown after receiving the Hello. I look into all_known_ciphersuites() in tls_suite_info.cpp and could not find any cipher with WITH_NULL. Is this not supported at the moment?
And if so, how could i add this? Or do I use the wrong policies.

Furthermore, I get the exception:
False assertion 'Expected DTLS' (expression rec.get_protocol_version()->is_datagram_protocol()) in read_dtls_record @/build/botan-Gdzg3C/botan-2.4.0/src/lib/tls/tls_record.cpp:428

[lieser]

Botan currently does not include support any WITH_NULL ciphersuite. And I also don't think a user of the library can add any new ciphersuite. So Botan would need to be extended to either support TLS_PSK_WITH_NULL_SHA256 or allow adding custom ciphersuites during runtime.

Regarding your error: Please try again with the latest 2.x version. It could be that you are affected by 1521aec.

[reneme]

For the sake of caution: You are trying to use a 'weak' ciphersuite that doesn't actually protect the confidentiality of your data. That is likely the reason NULL cipher suites are currently not supported by the library.

That said: I'm sure you have a good reason or use case for such a ciphersuite. I'd certainly be interested in learning more about that.

Anyway, @lieser is right, adding support for specific ciphersuites requires an extension of the library itself. If you are willing to work on that, we can certainly look into it. With NULL ciphers being an insecure cipher -- and therefore a potential footgun -- we should definitely look into an API safeguard. I.e. explicitly requiring the library user to enable such weak ciphers.

[mouse07410]

One use case I see - environments where confidentiality is prohibited, or you're legally obligated to provide a copy of your encryption key to the authorities. In such cases it might be better to drop the pretense of confidentiality altogether.

I hope to never be in such environments myself, but I know that they do exist.

[randombit]

Even with a policy hook guarding it I would be very hesitant about adding support for NULL ciphers. That is a gigantic footgun.

There are environments where you must log keys, but it would be far more effective to add support for SSLKEYLOGFILE format and allow the application to logs keys if it must.

[mouse07410]

It's not about logging the session keys and surrendering them after the fact - it's about providing your keys to authorities before the fact.

I don't insist on adding support for this - merely answering the question about what reason might drive a person to have it.

[reneme]

Even with a policy hook guarding it I would be very hesitant about adding support for NULL ciphers. That is a gigantic footgun.

I certainly agree. Nevertheless, I think @FlorianMueller87 has a reasonable use case (i.e. authentic but non-confidential communication). Instead of actually integrating support for NULL ciphers we could also provide a more flexible API so that library users can optionally plug into the instantiation of ciphersuite-components. Details would need to be carved out, of course.

The ciphersuite concept changed significantly from TLS 1.2 to 1.3 and the upcoming TLS 1.3 code doesn't account for that as much as I'd like, yet. We could take this API addition into account when refactoring this.

[FlorianMueller87]

Regarding the environment, I can give the following hint: I have to follow this document: doc
Find the issue in section 7.6.2.1.

[randombit]

As I understand that section it seems to also allow TLS_PSK_WITH_AES_128_GCM_SHA256, which is supported. Is the issue here that there is some other party which you do not control which insists on using NULL?

[FlorianMueller87]

Yes, you nailed it.