Re: [TLS] Working Group Last Call for

[Marsh Ray <[e-mail]>]

On 10/25/2010 04:14 PM, Martin Rex wrote:
> Martin Rex wrote:
>>
>> 2. SSLv2 deficiencies: "Sessions can be easily terminated"
>>
>>      o Sessions can be easily terminated.  A man-in-the-middle can easily
>>       insert a TCP FIN to close the session and the peer is unable to
>>       determine whether or not it was a legitimate end of the session.
>>
>>     I think this exaggerates the usefulness of the closy_notify(0)
>>     warning level alert as used in practice.

I disagree. It's simply stating the fact that SSLv2 cannot differentiate 
between a TCP level termination and a negotiated shutdown between the 
authenticated peers.

TLS can allows each peer to learn that the remote is finished sending 
data in an authenticated way. Though as you point out, TLS does not 
allow a peer to learn that the remote received the message, or in the 
case of a dropped connection to distinguish an attack from ordinary 
packet loss.

>>  By using an application
>>     level framing protocol to mark boundaries of data, it is fairly
>>     easy for application callers to compensate for this "lack" of SSLv2.

Yeah a lot of things easy in retrospect. :-)

>>     Many applications that use a framing protocol look only at their
>>     own framing rather than waiting for the close_notify alert exchange
>>     to _complete_.
>
> The semantics of the close_notify(0) Alert in TLSv1.2 (mostly unchanged
> from TLSv1.0).  Quoting from
>
> http://tools.ietf.org/html/rfc5246#section-7.2.1
>
>     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.

Sounds reasonable to me.

If you make it too burdensome, application developers will simply drop 
the connection. As it stands, there are very few applications that can 
cleanly exit their process if there are network connections hanging open.

> When pages are reloaded/refreshed or when users navigate before a
> web pages has completed loading all elements, it happens regularly
> that connections get terminated prematurely.

Well that sucks.

> In some situations the TLS-level close-notify might suggest a
> different behaviour than the common and likely app-level decision.
>
> What should a server do when processing an upload-request (HTTPS PUT),
> sends back a 200/201 to the Browser.  Does (or should) the server wait
> for the clients TLS close-notify and should the server rollback the
> PUT if the clients close-notify is not sent?

Good question. HTTP just wasn't designed for robust transactions, and 
HTTPS certainly wasn't designed to add them.

> If a server actually
> did rollback in absence of the client'c TLS close-notify, that would
> actually open(!) a vulnerability, i.e. an attacker could remove the
> clients TLS close-notify from the network causing the server to think
> it should rollback while the client believes the transaction was
> successful.

Yeah, good point. HTTP, even over TLS, is no substitute for a real 
two-phase commit.

Even 2-PC isn't perfect: Say the close-notify was to be replied with a 
close-ack. Mallory could simply drop one of those and the peers may 
still have a different picture about what happened.

So for every N-PC, there is an (N + 1)-PC which allows each side to be a 
little more epistemologically satisfied. Probably this is something to 
be decided at the application layer. Whether or not it was right 
decision for HTTP to be designed for N <= 1 is seems outside the scope 
of [TLS].

>  A "secure communication closure protocol" would need three
> legs, but that is clearly prohibited by the TLS spec for the
> close_notify alert.

TLS provides one authenticated shutdown message in each dirction, which 
is one more than the zero provided by SSLv2 or HTTP. Clearly there are 
some non-idempotent-transaction-oriented web/SOAP apps that would 
benefit from more. But at what layer should they be implemented?

For TLS, we could propose a Hello extension pair of to negotiate a 
higher N-PC:

For example:

         client                           server

     "Let's exchange 3 messages for shutdown in each direction"
     Hello ++ CloseNotifyN propose 6

                                   Hello ++ CloseNotifyN use 3
                                  "Yes, let's exchange 3"

          <========== app data =========>

Client is done sending app data:
     close_notify(-2)  ---->
                       <----      close_ack(-1)
     close_notify(0)   ---->


Server is done sending app data. These messages may be intermingled with 
those above.
                       <----      close_notify(-2)
     close_ack(-1)     ---->
                       <----      close_notify(0)

--------------------------

But it might make more sense to handle it at a higher layer. For HTTP, 
it might end up looking similar to HTTP challenge-response auth, which 
uses multiple requests over the same connection which really just form a 
single logical request.

- Marsh