Joe,
At 19:45 17/11/2014, Joe Touch wrote:
On 11/17/2014 10:58 AM, Eric Rescorla wrote:
>
>
> On Mon, Nov 17, 2014 at 12:27 AM, Bob Briscoe <bob.bris...@bt.com
> <mailto:bob.bris...@bt.com>> wrote:
>
> Ekr,
>
> There needs to be more behind the text on "Implementation Options"
>
<https://tools.ietf.org/html/__draft-rescorla-tcpinc-tls-__option-00#section-5>
>
> * If TLS is implemented in user-space, TCP will hold back TLS
> commands from the app until the 3-way handshake has completed, then
> pass it TLS commands via the datastream.
>
>
> I'm not sure why this has to be the case. There's assumed cooperation
> between the kernel and the user-space process, so this could also
> include the ability to read and write early.
It's always OK to write "early" to a TCP connection; the data just gets
queued up until the protocol handles it.
However, there's should never be "early read". The TCP API is defined as
holding back data from the user until the TWHS completes (or its
equivalent, e.g., for TFO).
"Cooperation" can occur within various components that implement *TCP*
(whether in userspace or kernelspace), but the user-level API should not
need to change for TCPINC.
I think the point Ekr (and Nico) are making is that TLS is really a
control channel within the TCP Data, so if an app understands that
distinction, it can preempt the handshake. Therefore it /can/ read
and process such control commands.
The app has to take responsibility for the consequences if the
handshake fails, but I think the point is that, in many scenarios
involving TLS, there will be no consequences - other than wasted
work. No 'real' data will have been consumed.
Bob
Joe
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
