Hi Ahmed, On Tue, May 05, 2020 at 09:05:53AM -0700, Ahmed Elsherbiny wrote: > Hi Peter, > > Unfortunately I am not privy to the reasons for choosing this particular > cipher suite.
If you can share them in private, I would be interested to hear about the use cases and why alternative configurations do not address it. > Sorry if my questions sounds naive - I'm really not into the security > domain. What would be the risks of using this implementation (with the > nonce issue and half-size key)? It would not be interoperable with other systems that implement the actual draft. And future versions of WolfSSL may change to fix this issue, there is already a patch here: https://github.com/wolfSSL/wolfssl/pull/2947 From the security point of view: - Use of half the hash length is non-ideal, but not critical. 128 bits should still be sufficient. - The nonce issue should not be problematic either. While the nonce is predictable, it does seem to include the record number (BuildTls13Nonce in the WolfSSL source code). That prevents reordering attacks. Predictability of the nonce should not be problematic as the HMAC key is different for the client and server and unpredictable which makes it hard for an attacker to breach integrity and authenticity. > Does it make it easier for an attacker to "fake" a certificate and > impersonate the server? No it does not. However, I am not aware of a broader analysis on this draft TLS 1.3 null cipher. Without such an analysis I cannot say with confidence whether your impersonation attack is present or not. And based on earlier communications in the IETF TLS mailing list, the TLS WG does not seem to be really interested in adopting the draft. Hence my earlier question about your use cases, maybe an alternative solution is possible. > My next question would be, what other cipher suites would you suggest? > I heard that TLS1.2 may get deprecated and so, not sure if that would > be a good option. TLS 1.2 will be there for several years more, I don't see it going away anytime soon. But between a standardized NULL cipher in TLS 1.2 and a non-standard NULL cipher in TLS 1.3, I would suggest going for the former since it is more widely available. And if you are concerned about compatibility, no good standard configuration will permit the NULL cipher, so that should not be an argument for choosing one over the other. Kind regards, Peter > Regards, > Ahmed > > On Mon, May 4, 2020 at 4:38 PM Peter Wu <pe...@lekensteyn.nl> wrote: > > > Hi Ahmed, > > > > On Mon, May 04, 2020 at 03:12:50PM -0700, Ahmed Elsherbiny wrote: > > > First of all, thank you again for creating the patch. I did test > > > it and was able to successfully decode some messages. > > > My implementation uses WolfSSL v4.3.0. > > > > > > I hope the patch will be merged in, please let me know if there's > > > any more info you need from my end. > > > > At the moment the patch is unlikely going to be merged pending further > > information from the relevant draft authors. Please be very careful with > > deploying your information, WolfSSL appears to have a bug in the > > implementation of the draft: > > https://github.com/wolfSSL/wolfssl/issues/2945 > > > > Is your implementation actually going to be used in production? What are > > the reasons behind choosing this draft proposal for TLS 1.3 null ciphers > > if I may ask? > > -- > > Kind regards, > > Peter Wu > > https://lekensteyn.nl ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
