Subject: [TLS] Working Group Last Call for draft-ietf-tls-ssl2-must-not-02

From: Joe Salowey <[email-masked]>
Date: Sun, 24 Oct 2010 21:16:47 -0700

This is an announcement of WGLC for draft-ietf-tls-ssl2-must-not-02.  The draft and its revisions can be found here:

http://tools.ietf.org/html/draft-ietf-tls-ssl2-must-not-02

Please send comments to the TLS list by November 17, 2010.  

Thanks,

Joe

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 Oct 2010 14:44:06 +0200

Joe Salowey <[email-masked]> writes:

> This is an announcement of WGLC for draft-ietf-tls-ssl2-must-not-02.
> The draft and its revisions can be found here:
>

I have read and support this document.

/Simon

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 25 Oct 2010 17:24:17 +0200

> Please send comments to the TLS list by November 17, 2010.  

I support this document.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Oct 2010 17:53:55 +0200

+1

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 25 Oct 2010 09:33:11 -0700

I support the document.

Mike

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Oct 2010 09:49:43 -0700

>Please send comments to the TLS list by November 17, 2010. 

I support the adoption of this draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Oct 2010 21:52:03 +0200 (MEST)

> Please send comments to the TLS list by November 17, 2010.  

This WGLC is about publication of the document, I assume.

In principle I'm OK with publication.

Re-reading it, I'd like to make two observations:

1. Per document header:
       Updates: 5246 (once approved)
   this document intends to update rfc-5246 _only_.  The text in
   Sections 1 and 3 does not limit itself to implementations of TLSv1.2,
   and I would support to similarily discourage the use of SSLv2 for
   existing implementations of TLSv1.0 and TLSv1.1.

   How about listing TLSv1.0 (rfc2246) and TLSv1.1 (rfc4346)
   as well in the Updates: of the document header,
   just like RFC5746 (TLS extension RI) does.

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.  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.
   Many applications that use a framing protocol look only at their
   own framing rather than waiting for the close_notify alert exchange
   to _complete_.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Oct 2010 23:14:08 +0200 (MEST)

>    own framing rather than waiting for the close_notify alert exchange

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.

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.

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?  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.  A "secure communication closure protocol" would need three
legs, but that is clearly prohibited by the TLS spec for the 
close_notify alert.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 25 Oct 2010 17:27:49 -0500

On 10/25/2010 04:14 PM, Martin Rex wrote:
>>     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

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

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

> that connections get terminated prematurely.

Well that sucks.

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

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

---

From: "t.petch" <[email-masked]>
Date: Fri, 29 Oct 2010 12:01:10 +0200

In the same vein as 1), I would like this to update RFC4347; there is a
presumption that updates to TLS should specify their applicability to DTLS and
it would be a shame if SSL continued to be used with DTLS.

Tom Petch

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: "Joe Salowey" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 25, 2010 9:52 PM
Subject: Re: [TLS] Working Group Last Call fordraft-ietf-tls-ssl2-must-not-02

> Joe Salowey wrote:
> >
> > This is an announcement of WGLC for draft-ietf-tls-ssl2-must-not-02.  The
draft and its revisions can be found here:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls