Re: Support tls-exporter as channel binding for TLSv1.3

On Wed, Aug 31, 2022 at 5:57 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> > OpenSSL should have an API for that (SSL_get_extms_support); I don't
> > know when it was introduced.
>
> This is only available from 1.1.0, meaning that we'd better disable
> tls-exporter when building with something older than that :( With
> 1.0.2 already not supported by upstream even if a bunch of vendors
> keep it around for compatibility, I guess that's fine as long as
> the default setting is tls-server-end-point.

Yeah, that should be fine. Requiring newer OpenSSLs for stronger
crypto will probably be uncontroversial.

> It would not be complex
> to switch to tls-exporter by default when using TLSv1.3 and
> tls-server-end-point for TLS <= v1.2 though, but that makes the code
> more complicated and OpenSSL does not complain with tls-exporter when
> using < 1.3. If we switch the default on the fly, we could drop
> channel_binding_type and control which one gets used depending on
> ssl_max/min_server_protocol. I don't like that much, TBH, as this
> creates more dependencies across our the internal code with the
> initial choice of the connection parameters, making it more complex to
> maintain in the long-term. At least that's my impression.

I think there are two separate concerns there -- whether to remove the
configuration option, and whether to change the default.

I definitely wouldn't want to remove the option. Users of TLS 1.2
should be able to choose tls-exporter if they want the extra power,
and users of TLS 1.3 should be able to remain on tls-server-end-point
if they need it in the future.

Changing the default is trickier. tls-server-end-point is our default
in the wild. We're not RFC-compliant already, because we don't
implement tls-unique at all. And there's no negotiation, so it seems
like switching the default for TLS 1.3 would impact interoperability
between newer clients and older servers. The advantage would be that
users of newer clients would have to opt in before servers could
forward their credentials around on their behalf. Maybe that's
something we could switch safely in the future, once tls-exporter is
more widely deployed?

> > If we want to cross all our T's, we should also disallow tls-exporter
> > if the server was unable to set SSL_OP_NO_RENEGOTIATION.
>
> Hmm. Okay. I have not considered that. But TLSv1.3 has no support
> for renegotiation, isn't it?

Right. We only need to worry about that when we're using an older TLS.

> And you mean to fail hard when using
> TLS <= v1.2 with tls-exporter on the backend's SSL_CTX_set_options()
> call? We cannot do that as the backend's SSL context is initialized
> before authentication, but we could re-check the state of the SSL
> options afterwards, during authentication, and force a failure.

Sounds reasonable.

> > Did you have any thoughts about contributing the Python tests (or
> > porting them to Perl, bleh) so that we could test failure modes as
> > well? Unfortunately those Python tests were also OpenSSL-based, so
> > they're less powerful than an independent implementation...
>
> No. I have not been able to look at that with the time I had,
> unfortunately.

All good. Thanks!

--Jacob