[gnutls-devel] GnuTLS | server auth: disable TLS 1.3 if no signature algorithm is usable (!987)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on tests/tls-neg-ext4-key.c: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171424205

>  	 .sig = GNUTLS_SIGN_RSA_PSS_SHA256,
>  	 .exp_kx = GNUTLS_KX_ECDHE_RSA,
>  	},
> -	{.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to refuse negotiating */
> +	{.name = "tls1.3 rsa-pss cert, rsa-sign key", /* we expect the server to attempt to downgrade to TLS 1.2, but it is not possible because it is not enabled */
>  	 .pk = GNUTLS_PK_RSA,
>  	 .prio = "NORMAL:-VERS-ALL:+VERS-TLS1.3",
>  	 .cert = &server_ca3_rsa_pss_cert,
>  	 .key = &server_ca3_rsa_pss_key,
> +	 .sig = GNUTLS_SIGN_RSA_SHA256,
> +	 .exp_kx = GNUTLS_KX_ECDHE_RSA,
> +	 .exp_serv_err = GNUTLS_E_INSUFFICIENT_SECURITY

This would fix this test, but not the underlying issue. What is my concern is that when this downgrade to tls1.2 happens the server thinks that there is a mismatch in the FFDHE negotiation and returns this error, which is not the case here if I understand well. The reason of failure is because the key wasn't of the right type (RSA_PSS), is that right?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/987#note_171424205
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190517/80a85472/attachment.html>