On Wed, Mar 10, 2021 at 3:57 PM 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.
This draft is
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. c
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
> From: Jonathan Hoyland
> Sent: Donnerstag, 11. März 2021 00:31
> One option that I haven't seen mentioned in the thread is
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14.
Thank you for the pointer to the draft.
> EAs let you send a certificate from either side of the
There is now an automated TLS interoperability site, heavily influenced by the
QUIC interoperability site. It us up and running. Get your implementations in
now! [1].
ECH is still a thing, getting implementation experience [2]. Will schedule a
meeting in the coming weeks to continue discussions
