Channel binding API

[Zash]

TLS 1.3 apparently invalidates existing channel binding methods, so one can no longer rely on SSL_get_finished, SSL_get_peer_finished returning non-NULL as an indicator that the tls-unique channel binding mechanism can be used.

It would be nice to have a simple API for an application to find out what channel binding mechanisms are available, and those values are.

Context:

• https://issues.prosody.im/1542
• https://mail.jabber.org/pipermail/standards/2020-May/037323.html

[kaduk]

As your transitively linked I-D (https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13) indicates, you're supposed to define a TLS Exporte (RFC5705) value for use for channel bindings for a given protocol. Such channel bindings are compatible with all TLS versions, including 1.3 and 1.2.

I'm not sure what kind of API you are imagining for "find[ing] out what channel binding mechanisms are available", though -- what kind of results would you imagine getting returned? AFAICT the SSL_export_keying_material() can be used as-is for an arbitrary (ideally, registered) exporter label, with no need for specific libssl support or an API to indicate such support.

[eforsberg]

Did read the relevant ID's and RFCs. Noted that RF 8446 (TLS 1.3) paragraph 7.5 redefines the PRF used in calculating exported key material from the one defined by RFC 5705. That does not seem to be implemented in neither OpenSSL 3.0 nor 1.1.1
This probably doesnt matter right now as I'm not aware of any use of the tls-exporter channel binding defined in the draft.
But probably should be fixed as the algorithm is in fact part of the TLS 1.3 RFC. Also note the difference in handling zero-length contexts, which needs to be accounted for.

[eforsberg]

never mind, I just found the tls13_export_key_material, looks good to me

[Zash]

So it seems to me that which channel bindings are usable depends on the TLS version, so I suppose I'm looking for the right place for some code like

channel binding usable (name) →
  case "tls-server-end-point":
    return SSL->has_peer_certificate?

  case "tls-unique":
    return SSL->version <= 1.2

  case "tls-exporter":
    return SSL->version >= 1.3

and something that then lets you get the corresponding blob easily.

[kaduk]

The exporter interface is available on all versions of TLS and is preferred over tls-unique for pre-TLS-1.3 versions.
A very brief thought suggests that the exporter interface is also preferred over tls-server-end-point for new protocols (again, for all TLS versions). I'm still a bit unclear on what the proposal is, exactly.

[Neustradamus]

I watch this important issue :)

[mvduin]

If the tls-exporter is going to be preferred for all TLS versions then it might be nice to at least have a convenience-wrapper for it, also to make sure people don't accidently specify use_context=0 and end up with an incompatible variant on pre-TLS-1.3.