For the text, I would change the last clause to "Implementations MUST NOT rely on the secrecy of the channel binding for their own security." (Although that is actually slightly stronger than RFC 5056, which only requires this for integrity protection of the underlying channel, i.e. TLS.)
W.r.t. context strings, the issue I'm thinking about is two protocols that both use this channel binding for a single session and somehow step on each other's toes. For example it's not hard to imagine one protocol building some kind of MAC-based auth protocol on this, and finding it's broken when deployed with another protocol that can be used as an oracle. I'm not sure this is an issue in practice, so much as, when thinking about a security analysis, a very common assumption is that only the protocol under analysis will generate messages of the given format. If the channel bindings aren't separated by context strings then any formal analysis would have to consider all protocols at the same time, which makes the analysis (literally) exponentially more complex for each new protocol. Also, in case it matters, there are authentication changes in TLS that do not change the state / move the state machine, for example Exported Authenticators. Regards, Jonathan On Thu, 11 Mar 2021 at 12:39, Sam Whited <s...@samwhited.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
