Re: Fwd: channel binding
On Mon, Jan 11, 2021 at 10:31:01PM +, 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
Re: Fwd: channel binding
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
Re: Fwd: channel binding
On Mon, Jan 11, 2021 at 09:26:30PM +, 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 (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
Re: Fwd: channel binding
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
Re: Fwd: channel binding
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
Re: Fwd: channel binding
On Sun, Jan 10, 2021 at 02:44:38PM +, 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
Fwd: channel binding
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
