Fwd: channel binding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: channel binding

Jeremy Harris
Hi,

What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?

I do not find them documented at
   https://www.openssl.org/docs/manmaster/man3/

but they are exported by the library and seem to be required, for
application channel-binding.
--
Cheers,
   Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

OpenSSL - User mailing list
On Sun, Jan 10, 2021 at 02:44:38PM +0000, Jeremy Harris wrote:
> Hi,
>
> What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?
>
> I do not find them documented at
>   https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$
>
> but they are exported by the library and seem to be required, for
> application channel-binding.

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://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material().

-Ben
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

Jeremy Harris
On 11/01/2021 08:20, Benjamin Kaduk wrote:

>> What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?
>>
>> I do not find them documented at
>>    https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$
>>
>> but they are exported by the library and seem to be required, for
>> application channel-binding.
>
> 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://tools.ietf.org/html/rfc8446#section-7.5), 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?

"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) ?
--
Cheers,
   Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

Jeremy Harris
In reply to this post by OpenSSL - User mailing list
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://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material().

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://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
)
as the label?   Does the label length for the SSL_export_keying_material()
call include the terminating NUL or not?
--
Cheers,
   Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

OpenSSL - User mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

Jeremy Harris
On 11/01/2021 22:07, Benjamin Kaduk wrote:
>> 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()?

Doh.  I was looking at the wrong routine; thanks.
But, per below, now moot.

> 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.

Right. So we have implementations out there using it; will the OpenSSL
project consider promoting it to supported status so that it doesn't
disappear in some future release?

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

Understood :)   Like all crypto...
--
Cheers,
   Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: channel binding

OpenSSL - User mailing list
On Mon, Jan 11, 2021 at 10:31:01PM +0000, Jeremy Harris wrote:

> On 11/01/2021 22:07, Benjamin Kaduk wrote:
> > > 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()?
>
> Doh.  I was looking at the wrong routine; thanks.
> But, per below, now moot.
>
> > 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.
>
> Right. So we have implementations out there using it; will the OpenSSL
> project consider promoting it to supported status so that it doesn't
> disappear in some future release?

I think you should treat them as if they are supported interfaces.
They're present in the list of "things that aren't documented but should be",
and do have some documentation-ish commentary in the public header file.

Any API change or removal would be against our support policy (and patches
to add man pages for them would also be welcome).

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

Yes ... though some we are more confident in than others :)

-Ben