On Tue, Jul 29, 2014 at 4:36 AM, Tero Kivinen <[email protected]> wrote:
> 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. > > Not to cross the streams or anything, but I'm wondering why an API requirement to protect the headers couldn't be inserted here. Obviously there are costs in latency in some of the RST cases described, but if it is an available knob, presumably it could get set when it is important to an application and left unset when not. I think if we have an "able to require it" knob, then having a knob for protecting the headers (and accepting the trade-off) makes sense. Just my two cents, obviously, Ted > > 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 >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
