On Sat, Aug 16, 2014 at 11:18:46AM -0700, John-Mark Gurney wrote: > Brandon Williams wrote this message on Fri, Aug 15, 2014 at 17:59 -0400: > > If I understand what I've read about channel binding, the idea is > > for one layer in the protocol stack to delegate authority for some > > part of its security requirements to another layer in the protocol > > stack that
That's one use-case and also a way to look at it. Here's another: > Well, lets be sepcific here.. it's to allow the authentication layer > be able to authenticate that the encrypted connection has not been > MITM or tampered with. Here's another: You want application-layer authentication (because, e.g., lower-layer auth won't do for some reason), and you don't want to double encrypt (once at the TCP layer, again at the app layer) because that'd be a terrible waste of resources. If you don't allow for channel binding then you'll either: a) limit this protocol only to unauthenticated encryption, forcing apps that need authentication to either disable this protocol or double-encrypt; b) be forced to add authentication options to the protocol that satisfy a large range of application authentication needs. Do you really want either of those? I seriously doubt it. To be fair there are use cases with a happy middle of the road: authenticate the server with, say, DANE or a reasonably strong PKI (i.e., with few trust anchors) and use the server's name as the "channel binding". For TCP this would manifest as something like a socket option or sockaddr extension by which the app can tell TCP what server name it wants. But that's not enough for at least some important use cases. Back to leaving session crypto to lower layers... That's desirable for several possible reasons: - HW might do better at offloading the crypto. That was/is reasonable for the IPsec case, but it's more of a stretch for the TCP case. - To reduce the number of cryptographic contexts needed for multi-user application protocols like NFS. - NEW since RFC5056: opportunistic security means you might get a lower-layer secure channel even if you could provide your own. Heck, we might end up with a situation in which the application necessarily will get a lower-layer secure channel no matter what (e.g., to avoid fingerprinting of application protocols). If you want to avoid double-crypto, and also want to avoid pushing authentication down to lower layers, then you really want channel binding. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
