IIUC a channel binding (in this context) provides a unique "name" for a
channel.
In the case where two distinct protocols running over the top of TLS use
this definition, they will both get the same channel binding.
It might be useful to pull out in the security considerations one
consideration from RFC 5056 that might be forgotten.
```
o The integrity of a secure channel MUST NOT be weakened should
their channel bindings be revealed to an attacker. That is, the
construction of the channel bindings for any type of secure
channel MUST NOT leak secret information about the channel. [...]
```
This means that a perfectly valid (even if currently undefined) use of a
channel binding might involve posting it to Twitter.
I don't follow kitten, but if there are multiple places that use this
binding then this might be a useful warning.
You cannot assume the channel binding of a channel is secret.
Alternatively using context strings allows for independent channel bindings
to be used by each over-the-top protocol, so perhaps requiring some unique
context string per usage type might be appropriate.
Perhaps these concerns are too out there, but just thought they warranted
at least a mention.
Regards,
Jonathan
On Wed, 10 Mar 2021 at 19:37, Nico Williams <[email protected]> wrote:
>
> +1
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
