On 28/07/14 17:29, David Mazieres wrote: > Olivier Bonaventure <[email protected]> writes: > >> My viewpoint is that it is too early to discuss about an API before we >> have a vague idea of the type of solution that will be >> developed. Multipath TCP worked on an API before the full protocol was >> specified but it is not yet supported by implementations. We will have >> a very idea of what the API could provide once we know clearly what >> will be in the protocol. Anyway, the API will only be useful once the >> protocol has been implemented... > > But given that we already have four concrete proposals on the table, is > it still too early to talk about API? > > I think two components of the API are very important: A) some kind of > session ID or channel binding, and B) some sort of out-of-band signal to > indicate that applications will make use of the session ID. As far as I > can tell, EKR seemed pretty happy to go with that API for use TLS. Are > there other proposers who would object to such an API? > > The reason it's useful to get this on the table early is that in the > abstract not all protocols are capable of producing a session ID with > the appropriate properties. In particular, the session ID must be > unique over all time with overwhelming probability even if one end of > the connection is malicious. As an example, I believe TLS could not do > this in the pre-RFC5929 days.
Right. So tcpcrypt and TLS based stuff can clearly do that. I'm very unclear about Joe's proposal in that respect, but if that were fleshed out, then I can't see why it'd be a problem. So I'm not at all clear how chatting about the API helps to pick a starting point from amongst those on offer. But maybe I'm missing something? S. > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
