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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 21, 2015 at 9:05 AM, Mirja Kühlewind <
[e-mail]> wrote:

> Hi Ekr,
>
> see inline.
>
> On 18.10.2015 16:23, Eric Rescorla wrote:
>
>>  > Hi Ekr,
>>  >
>>  > I did a quick review of draft-rescorla-tcpinc-tls-option-04, as an
>> individual (not as chair).
>>  >
>>  > Thanks for putting all the explanational text in there; at least for me
>> that was very helpful. I have a few comments and (potentially stupid)
>> questions:
>>  >
>>  > 1) Section 2 say that if there is a decryption failure/finished
>>  > failure, endpoint SHOULD signal a connection failure. Does it mean
>>  > that endpoint SHOULD/MUST also send a TCP RST? And do we really,
>>  > really need to close the connection here, or is there maybe a way to
>>  > think about falling back to TCP only…?
>>
>> I don't know if we *really* need to, but my reasoning here is that
>> we now know that the middlebox messed with the data and so failing
>> the connection is safer.
>>
>
> Not sure what safer in this sense actually means, but the point I was
> trying to make is, that this might be a case, where a connection might fail
> when trying to use tcpinc while a regular tcp connection might succeed. An
> application that does not even know that it is using tcpinc, thus might not
> be able to connect.


Well, as David points out, ENO specifically prohibits this. And I've
modified the
draft to say that.



>  > 2) The current proposal has the possibility that both endpoints
>>  > might not support the same chipper suite and therefore tcpinc will
>>  > not be used. Should we maybe think about picking a default one (or
>>  > set of default ones that can be ordered by preference) that must be
>>  > supported. I know that's hard, but for tcpinc, as the intention is
>>  > anyway ‚just‘ opportunistic encryption, that might make more
>>  > sense. Maybe we can specify something while at the same time saying
>>  > that the server should not expect that a specific chiper suite will
>>  > be available such that we still have a change to deprecate this
>>  > specification later…
>>
>> Well, there already is an MTI cipher suite (see: S. 3.5), but
>> someone could always be noncompliant, right?
>>
>
> Actually I overlooked this. However, to be correct you probably have to
> say that one should not only implement those but also offer at least one of
> them with the ClientHello.


 I could live with that.


 > 5) Section 3.2. says „… MUST respond to renegotiation with fatal
>>  > „no_renegotiation“ alert“. What does this mean for the TCP
>>  > connection?
>>
>> You should fail the connection. Any failure post-handshake should
>> lead to the same result.
>>
>
> My point is that 'fail the connection' does not mean anything for someone
> who want to implement this in TCP. I guess you mean send a TCP RST and
> close the socket connection...?


Yes. Once you adopt the position in ENO that you can only send ciphertext
then this naturally follows:

   Conversely, if a host receives an ACK segment containing an ENO
   option, then encryption MUST be enabled.  From this point the host
   MUST follow the encryption protocol of the negotiated spec and MUST
   NOT present raw TCP payload data to the application.  In particular,
   data segments MUST contain ciphertext or key agreement messages as
   determined by the negotiated spec, and MUST NOT contain plaintext
   application data.


 > 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.

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.



> 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?

-Ekr