Fwd: channel binding

[Benjamin Kaduk]

On Mon, Jan 11, 2021 at 09:26:30PM +0000, Jeremy Harris wrote:
> On 11/01/2021 08:20, Benjamin Kaduk wrote:
> > Current recommendations are not to use the finished message as the channel
> > binding but instead to define key exporter label for the given usage
> > (see https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*section-7.5__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcao40Dug$ ), using SSL_export_keying_material().


> Looking at the implementation, SSL_export_keying_material() only
> functions for TLS 1.3 .  This is not documented.  Is this a bug?

Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()?
For the latter, the man page says:

% SSL_export_keying_material_early() is only usable with TLSv1.3, and derives
% keying material using the F<early_exporter_master_secret> (as defined in the
% TLS 1.3 RFC).

I did try to check that the implementation was available for TLS 1.0 before
recommending it, but only halfheartedly.

> "Only defined for TLS 1.0 and above" says the docs; I can live
> with that.   But if 1.2 doesn't working with it, will SSL_get_finished()
> do so  (I an enforcing Extended-Master-Secret or not-Resumption) ?

> Follow-on question on SSL_export_keying_material() -
> what "label" should I supply?
> 
> I need to interwork with other implementations that are using
> SSL_get_finished() (client side) / SSL_get_peer_finished() (server side).
> Does that imply I should use "client finished"
> (per
> https://urldefense.com/v3/__https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml*exporter-labels__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcXtzE4eg$
> )
> as the label?   Does the label length for the SSL_export_keying_material()
> call include the terminating NUL or not?

If you need to interwork with other implementations/an existing protocol,
you have to stick with the Finished-based channel bindings; the exporter
interface is a new protocol mechanism and the whole protocol/ecosystem has
to be expecting to use it.

With TLS 1.2 and extended master secret this is not known to be broken (and
yes, that is a very carefully phrased statement).

And, for completeness, you generally won't include the terminating NUL
in the label length argument, but that will be defined by the protocol spec
that defines the exporter label.

-Ben