Martin Thomson <[email protected]> writes: > On 14 August 2015 at 11:30, <[email protected]> wrote: >> Do you think TCP-ENO should specify the >> mechanism or the requirement? > > Perhaps neither. At one level, this need only negotiate what crypto > is in effect.
Well, the charter requires TCPINC to have some kind of session ID or other authentication mechanism. If by neither you mean you don't want that mechanism to be part of TCP-ENO, then TCP-ENO won't be very useful. Strip out the session ID and you're mostly left with option kind multiplexing, which could equally well be achieved through some simpler RFC6994-like thing. (The negotiation and aa bits can't be secured without some sort of cross-spec requirements on the session ID.) > At this stage, not knowing what is going to happen where, bundling > things together doesn't help. I don't understand this comment. The whole point of TCP-ENO is to make progress on knowing what is going to happen where, so as to facilitate agreement on the crypto spec itself. ENO can facilitate agreement on a spec because it enables a spec-independent API. Hence, if we standardize TCPINC before TLS 1.3 or large options have been standardized, we haven't given up the ability to leverage those other technologies in the future. Is your objection that this is the wrong goal (because there is no useful spec-agnostic API), or that TCP-ENO fails to meet the goal (because you envision specs unable to accommodate TCP-ENO's session ID requirements), or that there's some better way to try to break the working group deadlock (which I'd be glad to try)? If you don't object to the basic premise of TCP-ENO, it would be helpful if you could provide a specific suggestion for how you would like to see the the draft changed. Additionally, if you can cook up a specific (albeit contrived) example that demonstrates the shortcomings of the existing TCP-ENO draft (maybe with added computational indistinguishability of session IDs in response to list feedback), this would be quite helpful in framing the discussion. Thanks, David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
