Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla <[e-mail]>]

On Wed, Nov 9, 2016 at 1:31 AM, Martin Rex <[e-mail]> wrote:

> Salz, Rich wrote:
> >> the PDUs are still pretty much predictable
> >> heuristically (by their ordering), even when they're padded.
> >
> > ...
> >
> >> So besides being completely pointless, can you describe any realistic
> >> problem that is worth breaking middleware at the endpoints so badly?
> >
> > I found the language difference interesting.  We could conduct an
> > interesting thought experiment by reversing the emphasis on each
> > of the above fragments.  But I won't.
> >
> > Instead, I'll point out that this is in-charter, in-scope, and WG
> consensus
> > has generally been to "encrypt all the bits" as much as feasible.
>
> The problem here is that this breaks (network) flow control, existing
> (network socket) event management, and direction-independent connection
> closure, and does so completely without value.
>
> When TLS records with AppData can be left in the network socket while
> the application layer is not ready to process & consume it, then TCP flow
> control works better in high load situation.
>
>
> The semantics defined for the TLS Closure Alert in SSLv3->TLSv1.2
> is somewhat difficult for full-duplex communication, direction-independent
> shutdown, and confirmation of receipt:
>
>    https://tools.ietf.org/html/rfc5246#section-7.2.1
>
>    7.2.1.  Closure Alerts
>
>    The client and the server must share knowledge that the connection is
>    ending in order to avoid a truncation attack.  Either party may
>    initiate the exchange of closing messages.
>
>    close_notify
>       This message notifies the recipient that the sender will not send
>       any more messages on this connection.  Note that as of TLS 1.1,
>       failure to properly close a connection no longer requires that a
>       session not be resumed.  This is a change from TLS 1.0 to conform
>       with widespread implementation practice.
>
>    Either party may initiate a close by sending a close_notify alert.
>    Any data received after a closure alert is ignored.
>
>    Unless some other fatal alert has been transmitted, each party is
>    required to send a close_notify alert before closing the write side
>    of the connection.  The other party MUST respond with a close_notify
>    alert of its own and close down the connection immediately,
>    discarding any pending writes.  It is not required for the initiator
>    of the close to wait for the responding close_notify alert before
>    closing the read side of the connection.
>
>
> The issue here is that the receiving TLS stack, when processing an
> incoming TLS CloseNotify Alert, will typically immediately respond
> with a TLS CloseNotifyAlert on its own, precluding the application
> from sending any further data in the other direction in response
>
> When hiding the TLS record ContentType, then pre-reading and coalescing
> (=streaming) application data records suddenly becomes a problem, because
> receiving and processing a hidden TLS CloseNotify Alert will cause
> a TLS CloseNotify Alert response (an alleged indicator for a graceful
> connection closure) being generated and returned even before
> the application has (a) seen and (b) had a chance to respond to the
> latest batch of application data.
>
>
> To prevent this from happening, and leave the decision to the application
> of whether to read a (potential) CloseNotify alert from the wire,
> I would have to go back to trickling TLS records (including those
> pathologically fragmented ones from Google) to the application
> whenever TLSv1.3 is negotiated.
>

I'm not quite following who's who in this scenario, so some potentially
stupid
questions below.

As I understand it, you have the following situation:

- A Web application server
- Some middleware, which comes in two pieces
  - A crypto-unaware network component
  - The TLS stack (you control this piece as well, right?)
- The client

So, in this case, the client sends a flight of records which (ignoring
rehandshakes
and other TLS 1.3 post-handshake shenanigans such as KeyUpdate) contains
a bunch of application data traffic potentially terminating in a
close_notify. In
TLS 1.2 you inspect the content type, deliver all the app data to the TLS
processor,
but hold the close_notify. And those packets are in turn handed to the Web
server/application. Is that correct? If so, when do you deliver the
close_notify
and how do you know how?

In the TLS 1.3 case, as I understand it, you can't see which packets are
which
so you just have to deliver all the packets to the TLS processor, and if
one of
them contains a close_notify, then it responds with its own close_notify
(I'm getting this from the text above where you say "being generated and
returned even before the application has..."). Is that right as well? Can
you explain
further why this is a problem: are you expecting that if you send
application
data to the client after sending the close_notify itself, the client will
consume
it? Or are we somehow concerned with side effects on the application server?

Can you help me understand?

thanks,
-Ekr








There is a similar (slightly smaller) issuer with the coalesced TLS
> handshake/alert/css record processing during the TLS handshake phase,
> Feeding the whole "flight" already waiting in network buffers into
> the TLS stack at once will no longer be possible, with hidden ContentTypes
> I will have to start trickling TLS records with handshake messages into
> the TLS stack, and have to poll the handshake state after each TLS record
> in order to heuristically determine whether the next record waiting in
> the network buffer is (likely) a record with AppData--which I must leave
> in the network buffer until the application caller explicitly calls for it.
>
>
> The really painful issue are constantly mind-changing browsers loosing
> interest in responses and sending TLS CloseNotify instead of TCP RSTs
> -- I don't know how to deal with these without breaking the current
> (network socket) event semantics for the app.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>