On 28 July 2014 09:44, Eric Rescorla <[email protected]> wrote: > We can certainly explore this. The tcpcrypt API looked basically fine, and > it > seemed like it would be an OK match with my draft, but I admit I haven't > actually tried to do the detail work.
That was my take as well. The API we're talking about has the following functions: 1. No API and get opportunistic security 2. Able to disable it 3. Able to require it 4. Able to access peer authentication credentials (often in combination with 3) 5. Able to access channel binding information (TLS unique, etc...) My assessment is that all of the proposed solutions have the necessary primitives to support all of these functions, or could be trivially modified to do so, assuming of course that all the usual concerns are addressed. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
