Re-iterating that CBs may be public seems sane. I'll add some text. along the lines of:
> Channel bindings do not leak secret information about the channel and > are considered public. Implementations MUST NOT use the channel > binding to protect secret information. With regard to context strings, I don't think it gets us any benefit. If two protocols get the same channel binding and something changes (eg. the protocol is resumed over a new TLS session), both channel bindings break either way. We'd also want to create some sort of registry for these strings, most likely which adds a lot of overhead for no benefit that I can see. Maybe there's some benefit to having separate channel bindings per protocol and per channel and not just per channel that I can't see though. —Sam On Wed, Mar 10, 2021, at 18:57, Jonathan Hoyland wrote: > 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
