Hi again,
see below.
On 21.10.2015 18:19, Eric Rescorla wrote:
> 8) Further the draft says in section 6, that there are two options
> for implementation. And I disagree there. tcpinc should always be
> implemented in the kernel and only if there is potentially an app
> that also implements TLS there might be a config option to allow the
> app to do the TLS handling if successfully negotiated in TCP. It is
> not an option to have a tcpinc implementation that relies on the
> possibility that the app might have TLS implemented because then we
> are end up at a the state where we already are.
We're defining a wire protocol here, so specifying particular
implementation tactics seems out of scope. With that said, I
don't think your assessment that we're back at the same state
we always were. As I think I pointed out when I first introduced
this draft, it addresses two problems with the same wire protocol:
1. The basic TCPINC use case.
2. Out-of-band negotiation of application-level TLS.
An application-level implementation is totally consistent with #2.
First of all, you have a section on implementation in the draft, I'm just
commenting on what's written there.
I think David, made this point as well: tcpinc is charter for case 1,
that means there MUST be a kernel implementation.
I don't think this follows at all. The charter doesn't say anything about kernel
implementations. It says "The protocol must be usable by unmodified
applications" and
"The protocol must not require any authentication or configuration", but neither
of these require a *kernel* implementation. For example, one might implement
things with a divert socket (as the tcpcrypt implementation at
https://github.com/scslab/tcpcrypt does, though I know they have a kernel
implementation.). So this means you need a whole-system implementation
but doesn't mean you need a kernel one.
Okay, you are right, I was using 'kernel implementation' as a synonym for
'stand-alone implementation' or 'whole system implementation' as you just
named it and that's wrong; sorry. And I was also naturally assuming that we
sooner or later want to provide a kernel implementation here. But that's a
different story.
However, the point is that the second option where tcpinc would rely on an
implementation in the app as written in you draft is not an option for tcpinc:
" o Implement just the TCP-TLS negotiation option in the operating
system kernel with an interface to tell the application that TCP-
TLS has been negotiated and therefore that the application must
negotiate TLS."
Another concrete scenario (which is attractive for a TLS implementation) is to
use a minimal kernel component (or a divert socket) to do the ENO options
with a modified libc to actually do the TLS negotiation and data handling.
This would also provide system-wide support but would not be in the kernel.
I don't see anything in the charter which prohibits this.
In don't really see how to deploy this, because than you have a kernel
implementation that requires a certain lib to be installed. In this case you
probably should implement the lib in the kernel right away.
Case 2 might be supported but doesn't have to to fulfill our charter. Of
course I agree that case 2 makes a lot of sense if we use tls.
However, the point is, as long as the doc says that you can fulfill the
specification of tcpinc even though you have an implementation that only
uses tcpinc if TLS is supported by the app, this doc is not a tcpinc doc
because it does not address our charter.
I think this is kind of a semantic distinction, but would you consider it
satisfactory
if this were rewritten to indicate that it is possible to build an
implementation which will
interoperate with a system-wide implementation (scenario 1) using solely an
application-level
technique?
If you mean a user-space implementation as provided by tcpcrypt, where you
redirect TCP traffic back into user-space (and all tcpinc is implemented in
user space without kernel modifications), then yes that's okay.
At this point it is important to have a full and stand-alone implementation
that can be used with any app to show the feasibility and check that the
given specification is clear and complete.
However, this can, from my point of view, only be a intermediate solution to
enable faster deployment, where the final goal would still be a kernel
implementation. But that's my personal point of view here.
Mirja
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
