Re: [tcpinc] Quick review of draft-rescorla-tcpinc-tls-option-04

[Mirja Kühlewind <[e-mail]>]

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