Also, I'd add this: - consider DANE-like schemes
- ideally: include DANE as an option from the get-go It's worth thinking a bit about what that means. Applications can always authenticate at the app layer with channel binding, but naive apps couldn't get opportunistic authentication that way. Which is why having server authentication in the protocol as an option is desirable. On the client side that might mean that either the app uses something like getsockopt() to find out what public signature key the server used, or setsockopt() to tell the TCP stack what keys the server may use. The former will be easier on TCPINC implementors, but the latter allows failure sooner (for what that's worth). Also, key per-service name, port, or host? All can be supported, at the cost of some additional DNS queries. If port numbers are not integrity protected then key per-host will have to be it... On the server side, the main consideration is the key per-service name/port/host matter. If per-service/port then the application would have to provide the private key (setsockopt()) or do the signing (oof). Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
