It is my understanding that EAP-TLS and EAP-TTLS do not trust in WPA2 4-Way handshake, essentially establishing an authenticated tunnel between client and server independant on the WPA2 protocol.
Your understanding is wrong. EAP-TLS and EAP-TTLS (as well as EAP-PEAP) are methods used to authenticate a supplicant (i.e. client) to a RADIUS server when using WPA/WPA2-Enterprise (i.e. 802.11i). All of them create a TLS tunnel between the supplicant and the RADIUS server through which the authentication is passed.
In an 802.1X transaction such as this, the client is not actually connected to the network until they are authenticated. The device the client connects to will proxy the 802.1X transaction from the supplicant to the RADIUS server. Only after a successful authentication is the client allowed to finish establishing the connection to the network.
In the case of 802.11, it is after the successful authentication that the client can complete the connection and establish encryption with the access point (often referred to as the WPA2 handshake).
In this scenario, would KRACK reveal plaintext from the victim, or it would be unable to break the TLS tunnel and confidentiality would be ensured?
KRACK would be unable to break the TLS tunnel used by the EAP method as KRACK does not attack the TLS protocol. Rather KRACK attacks the WPA2 handshake which establishes the encryption keys to be used between the client and access point. It is the encryption between the client and the access point that is vulnerable.
The TLS tunnel used by EAP methods is established between the supplicant and the RADIUS server, not between the client and the access point. Once the authentication completes, the TLS tunnel is torn down.
Post successful authentication, when the process continues connecting to the network, is when the WPA2 handshake takes place and KRACK would come into play. This will then compromise the encryption between the client and the access point.