Re: [tcpinc] Revised version of TCP-ENO

[David Mazieres <[e-mail]>]

Martin Thomson <[e-mail]> writes:

> On 14 August 2015 at 11:30,  <[e-mail]> 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