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

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

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.

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

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

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

Mirja