Channel bindings are generally just horribly named. The `channel` in that case would consist solely of the agreed key, and agreement on it would prove that not only was that the key, but also that nothing else was established. Therefore you wouldn't be able to convince one side that it was just a manually entered key, and the other that it was a TLS 1.2 PSK, which is obviously a plausible threat.
Regards, Jonathan On Fri, 15 Jun 2018, 17:13 Benjamin Kaduk, <[email protected]> wrote: > On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote: > > Agreement on a channel binding in the identity would prove, amongst other > > things, agreement on the KDF used to derive the PSK, whereas the TLS > > handshake proves agreement on the PSK itself, but says nothing about the > > derivation of it. > > This way means you don't have to worry about collisions between hash > > functions, as long as the channel binding is correctly constructed. > > While this is an interesting way to think about things, it's unclear to me > how general it is for framing the problem. That is to say, there is not > necessarily a "channel" used to provision what TLS 1.3 calls "external > PSKs". > My model for them includes an administrator typing a hex string into a > configuration > file on both ends of the connection, or a manufacturer burning a key into > ROM > for an IoT device -- what would the "channel" be those cases? (Or do I > completely > misunderstand what you're trying to do?) > > -Ben >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
