[gnutls-devel] GnuTLS | gnutls_certificate_type_get*: ensure that the default type is returned (!806)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on lib/constate.c:

>  		dst->prf = src->prf; \
>  		dst->grp = src->grp; \
>  		dst->pversion = src->pversion; \
> +		dst->client_ctype = src->client_ctype; \

> Following that your first solution adheres to the spec and makes sure that the certificate type negotiation extensions are also renegotiated under TLS 1.3. Indeed we may end up in a situation where there is a certificate type mismatch between the newly negotiated type and the previously exchanged certificate. The question is, is this a problem?

Let's take an example. If we keep the strict RFC behavior, that if we adopt the behavior above, it means that in a resumed session `gnutls_certificate_type_get()` may return `raw` while `gnutls_certificate_get_peers` will return an X.509 certificate. How would you see that behavior as an potential user of these functions? It looks quite dangerous to me, especially if one cert can be read both ways (e.g., a specially crafted one - probably impossible in that example).

> In the former case, should we propose a modification of the spec perhaps for this edge case? What do you think?

The only problematic case would be a situation where a protocol requires negotiation with X.509 certificates, while it allows resuming a session with a different certificate type for use in post-handshake authentication. Not sure how possible is that scenario, and it looks like a harmless limitation but maybe, we can even handle it the following way:

if the resumed session negotiates a different certificate than the original one, then all the authentication info data (i.e., certificates from the original session) are cleared up. That way the application will see any empty certificate, and could use the new certificate type in a potential post-handshake auth.

What do you think?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/806#note_118010022
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/20181117/17d0373d/attachment.html>