Martin Thomson writes: > The API we're talking about has the following functions: > > 1. No API and get opportunistic security > 2. Able to disable it
These first two are ok. > 3. Able to require it This can seen as stepping stone for the next higher level of security, even though the tcpinc idea was that it would be oppurtunistic in a sense that if things fail then we fall back to plain text tcp. > 4. Able to access peer authentication credentials (often in > combination with 3) This one is quite hard in practice, and will depend a lot about the actual protocol we select. In the tcpcrypt there is no way to do authentication, so there cannot be any authenticated credentials there. In TLS there is, but getting that information to the application is quite complex, and the formats are different (certificates, identities, user names etc). So I think we should move this to as lowest priority item. > 5. Able to access channel binding information (TLS unique, etc...) This is much easier to get, and this would allow doing the end point authentication inside the applications. This would probably also provide a way for application to see whether the connection is protected with tcpinc. If if this returns something, there is tcpinc in place, if this returns error or empty then plain old tcp is used. > 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. I think that requiring 4 is not something we should decided here. It is ok if we go with the TLS approach, as the authentication protocols are already there. If we go with the tcpcrypt approach, then requiring it to support authenticated DH / RSA in addition with unauthenticated will make the protocol more complex. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
