Mailing List Archive

On Channel Binding over SMTL/TLS
Hello,

I have a general question on channel binding, exim is one of the few
application offering CB.

RFC 5929 Channel Bindings for TLS defines the tls-unique channel
binding, stating that there was an old tls-unique, which was bad. The
new tls-unique uses the most recent TLS Finished message sent in the
token, whereas the old tls-unique used the first TLS Finished message.

Commit b1a32a3ce673 adds channel binding to openssl/exim, using the
function SSL_get_peer_finished(). Compare this to the OpenLDAP
implementation, where libldap/tls_o.c:tlso_session_unique() uses
SSL_session_reused(s) ^ !is_server ? SSL_get_finished(s) :
SSL_get_peer_finished().

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_gsasl_authenticator.html
says for server_channelbinding: “However, Channel Binding in TLS has
proven to be vulnerable in current versions. Do not plan to rely upon
this feature for security, ever, without consulting with a subject
matter expert (a cryptographic engineer). ”. Is this vulnerability
addressed in RFC 5929?

“This is only usable by mechanisms which support "channel binding"; at
time of writing, that’s the SCRAM family. When using this feature the
"-PLUS" variants of the method names need to be used. ” ? GS2-KRB5 also
supports channel bindings.

The document does not state, that the tls-unique channel binding is
used by exim and tls-server-end-point is not used.

Would you mind implementing Channel Binding also using Cyrus SASL and
doing interoperability test (e.g. beween GnulTLS+Gsasl vs OpenSSL+Cyrus
SASL)? OpenLDAP has the file cyrus.c, which implements channel binding
in such a way, that it works with the Windows Active Directory (but I
have some concerns to the implementation, as it enforces channel
binding over SASL GSSAPI, whereas “RFC 4752 SASL GSSAPI” says, that
SASL GSSAPI does not allow channel binding).

Have you done any interoperability tests for the channel binding (e.g.
can the Outlook MTA do SASL GSSAPI using Channel Binding)?

Greetings
?????


--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: On Channel Binding over SMTL/TLS [ In reply to ]
On 10/01/2021 11:47, ????? ???????? via Exim-dev wrote:
> RFC 5929 Channel Bindings for TLS defines the tls-unique channel
> binding, stating that there was an old tls-unique, which was bad. The
> new tls-unique uses the most recent TLS Finished message sent in the
> token, whereas the old tls-unique used the first TLS Finished message.
>
> Commit b1a32a3ce673 adds channel binding to openssl/exim,

2019/11. Actually only adds the OpenSSL support; channel binding
under GnuTLS was already there (since the introduction of the gsasl
driver, 2012/02).

> using the
> function SSL_get_peer_finished(). Compare this to the OpenLDAP
> implementation, where libldap/tls_o.c:tlso_session_unique() uses
> SSL_session_reused(s) ^ !is_server ? SSL_get_finished(s) :
> SSL_get_peer_finished().

Exim only calls SSL_get_peer_finished() on the server side.
The client side calls SSL_get_finshed().

>
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_gsasl_authenticator.html
> says for server_channelbinding: “However, Channel Binding in TLS has
> proven to be vulnerable in current versions. Do not plan to rely upon
> this feature for security, ever, without consulting with a subject
> matter expert (a cryptographic engineer). ”. Is this vulnerability
> addressed in RFC 5929?

The docs warning was added in 2018/07. RFC 5979 was published 2010/07.
Draw your own conclusion.
I'm not a cryptographic engineer, and my advice is worth what you're
paying for it.

For reference, RFC 8446 (TLS 1.3) was published 2018/08. The situation
might be different in 1.3 vs. previous TLS versions. There appears to
have been recent work on the subject:
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

- which mentions a "triple-handshake" vulnerability found for RFC 5929
(I infer, for TLS 1.2) which in turn can be mitigated by using Extended
Master Secret. See RFC 7627; Exim enforces the requirements of
https://tools.ietf.org/html/rfc7677#section-4 (in short, if TLS Resumed
then require Extended Master Secret).

NOTE: I do not know if this is the concern that warranted the warning
in the Exim docs.
You should, as it says, consult a crypto expert.


> Would you mind implementing Channel Binding also using Cyrus SASL and
> doing interoperability test

The Cyrus SASL documentation is a disaster zone, from my memory of the
last time I tried to look. I'm not enthusiastic about doing anything
with that library.

> Have you done any interoperability tests for the channel binding

No.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##