To expand a little on what tptacek said, and with the disclaimer that I have no idea what I'm talking about, ...
If you find your nearest copy of the OpenSSL command-line tool and run "openssl ciphers -v ALL", you'll get a list of all of the cipher suites that your particular OpenSSL build supports. For example:
An SSL/TLS cipher suite is a specific combination of a key exchange method (the method the TLS peers use to exchange the keys used with the bulk cipher), an authentication method (the method the TLS peers use to authenticate each other), a bulk encryption cipher (the symmetric cipher used to encrypt data sent between the peers), and a message authentication code (the method used to verify that data isn't modified in transit). These four things are the "Kx=", "Au=", "Enc=", and "Mac=" columns in the output above.
Virtually all X.509 certificates issued by certificate authorities today for use with SSL/TLS are for use with cipher suites that use RSA authentication. You generate an RSA key pair, stuff your public key in a certificate signing request, staple some money to the CSR, and hand it to the CA. The CA takes your money, verifies that you are in control of the hostname(s) you want a certificate for, creates a certificate containing your public key (and other X.509 goop), signs the certificate with their private key, and hands the certificate to you. For better or worse, this isn't changing.
What is being proposed is the removal of cipher suites that use RSA for key exchange ("openssl ciphers -v kRSA") from TLS 1.3. There are many other cipher suites that use RSA for authentication but use other methods for key exchange ("openssl ciphers -v aRSA:\!kRSA"), and some of these other key exchange methods have the rather nice property of perfect forward secrecy.
(Note that OpenSSL's list of ciphers isn't exhaustive, especially if you're using the lame OpenSSL build that Apple ships. But even if you're using an up-to-date OpenSSL build, the various SSL and TLS RFCs specify so many cipher suites that even OpenSSL doesn't support them all.)
If you find your nearest copy of the OpenSSL command-line tool and run "openssl ciphers -v ALL", you'll get a list of all of the cipher suites that your particular OpenSSL build supports. For example:
An SSL/TLS cipher suite is a specific combination of a key exchange method (the method the TLS peers use to exchange the keys used with the bulk cipher), an authentication method (the method the TLS peers use to authenticate each other), a bulk encryption cipher (the symmetric cipher used to encrypt data sent between the peers), and a message authentication code (the method used to verify that data isn't modified in transit). These four things are the "Kx=", "Au=", "Enc=", and "Mac=" columns in the output above.Virtually all X.509 certificates issued by certificate authorities today for use with SSL/TLS are for use with cipher suites that use RSA authentication. You generate an RSA key pair, stuff your public key in a certificate signing request, staple some money to the CSR, and hand it to the CA. The CA takes your money, verifies that you are in control of the hostname(s) you want a certificate for, creates a certificate containing your public key (and other X.509 goop), signs the certificate with their private key, and hands the certificate to you. For better or worse, this isn't changing.
What is being proposed is the removal of cipher suites that use RSA for key exchange ("openssl ciphers -v kRSA") from TLS 1.3. There are many other cipher suites that use RSA for authentication but use other methods for key exchange ("openssl ciphers -v aRSA:\!kRSA"), and some of these other key exchange methods have the rather nice property of perfect forward secrecy.
(Note that OpenSSL's list of ciphers isn't exhaustive, especially if you're using the lame OpenSSL build that Apple ships. But even if you're using an up-to-date OpenSSL build, the various SSL and TLS RFCs specify so many cipher suites that even OpenSSL doesn't support them all.)