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 <peter@xxxxxxxxxxxxx> 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
