Subject: [xmpp] 3920bis-07

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Apr 2010 16:53:03 -0600

Based on feedback received during and after IETF 77, I have submitted an
updated version of draft-ietf-xmpp-3920bis. The changes from -06 are:

1. Added a note about the TLS server_name extension, including a
reference to RFC 4366

2. Added a note about not trusting the stream header attributes in the
absence of TLS

3. Added a note about matching the results of an SRV lookup against the
input, similar to text in draft-daboo-srv-email

4. Added a security consideration about weak passwords

5. Added a security consideration about the use of DNS

6. Added a security consideration about the use of XML, including a
reference to RFC 3023

7. Prohibited TLS renegotiation

Feedback is welcome as always.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Apr 2010 06:16:36 -0600

> 6. Added a security consideration about the use of XML, including a

It seems that a reference to RFC 3470 might be (more) appropriate, so
I'll add that in the next version.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 8 Apr 2010 18:47:24 +0500

> 7. Prohibited TLS renegotiation
I think the text should probably clarify that the secure renegotiation
described in RFC 5746 is allowed (or is that also forbidden?).

A far more important security issue is SSLv2. It's horribly broken. It's
disabled in all modern web browsers. It's supported by several servers
listed on <http://xmpp.org/services/>. This is something I'd be happy to see
forbidden.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Apr 2010 09:42:00 -0600

On 4/8/10 7:47 AM, Waqas Hussain wrote:
> On Thu, Apr 8, 2010 at 3:53 AM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 

That's a matter for discussion. The security folks I've talked with
suggest that it's easier all around to forbid renegotiation, but we can
chat about that on this list.

> listed on <http://xmpp.org/services/>. This is something I'd be happy to
> see forbidden.

What exact concern do you have, and what text would you suggest? Do you
propose that we (try to) prohibit or strongly discourage XMPP clients
and servers from offering or using SSLv2? That's already covered by
Appendix E.2 of RFC 5246 as far as I can see.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Apr 2010 15:40:10 -0600

> Appendix E.2 of RFC 5246 as far as I can see.

Feedback is welcome...

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Apr 2010 22:16:01 -0600

>> Appendix E.2 of RFC 5246 as far as I can see.

How is this text?

   Implementations of TLS typically support multiple versions of the
   Transport Layer Security protocol as well as the older Secure Sockets
   Layer (SSL) protocol.  Because of known security vulnerabilities,
   XMPP servers and clients SHOULD NOT support or offer SSL 2.0.  See
   Appendix E.2 of [TLS] for further details.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Apr 2010 08:45:06 +0200

>    Appendix E.2 of [TLS] for further details.

I propose MUST NOT instead of SHOULD NOT.

The SSL 2.0 protocol is broken [1] and several TLS implementations
doesn't implement it at all or disable it by default.

I don't believe there is any justification left to be permissive about
SSL 2.0 today.  Especially in a "modern" protocol like XMPP.

RFC 5246 appendix E.2 may lead implementers down the wrong path: it is
mostly about SSL 2.0 interoperability.  We don't want anyone to be
implementing that today.

/Simon

[1] http://www.gnu.org/software/gnutls/manual/html_node/On-SSL-2-and-older-protocols.html

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Apr 2010 12:51:43 -0600

> mostly about SSL 2.0 interoperability.  We don't want anyone to be

I prefer MUST NOT. My only question is: can applications that use a TLS
library easily disable SSL 2.0 support, or are they dependent on the
library?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Apr 2010 08:22:10 +0200

> library easily disable SSL 2.0 support, or are they dependent on the

GnuTLS doesn't implement SSL 2.0 at all.  I believe SSLv2 has been
disabled by default in NSS for some time already.  It is easy to disable
SSLv2 in OpenSSL (just replace any calls to SSLv2_client_method with a
call to TLSv1_client_method).  I'd be surprised if it is not easy to
disable SSLv2 in Windows too, maybe someone can confirm that?

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Apr 2010 17:26:45 -0600

> disable SSLv2 in Windows too, maybe someone can confirm that?

Thanks for the information, that helps.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 29 Apr 2010 09:10:54 +0200

> I propose MUST NOT instead of SHOULD NOT.

Should servers reject SSLv2 client hellos that indicate that the client 
also understands SSLv3 and TLSv1 (such as those generated by openssl's
SSL_v23_method)?

philipp

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Apr 2010 09:53:37 +0200

Philipp Hancke <[email-masked]> writes:

> Should servers reject SSLv2 client hellos that indicate that the
> client also understands SSLv3 and TLSv1 (such as those generated by
> openssl's SSL_v23_method)?

I don't think that follows.

Clients and servers should, however, reject any negotiation of SSLv2
because that is an insecure protocol.  I don't believe there are any
significant security problems in offering a SSLv2 client hello that ends
up negotiating TLSv1?  FWIW, GnuTLS supports SSLv2 client hellos in
server mode.

On the other hand, I don't see the point of sending a SSLv2 client hello
if neither client and server will accept SSLv2.  But I also don't see a
strong reason to forbid that in the specification.  One reason to forbid
it may be to reduce complexity.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Apr 2010 11:21:42 +0100

> it may be to reduce complexity.

Clients sending it also won't negotiate compression.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Apr 2010 21:49:27 -0600

> up negotiating TLSv1?  FWIW, GnuTLS supports SSLv2 client hellos in

Why offer it or request it if no one will support it?

> it may be to reduce complexity.

Another reason might be that if we make a strong statement in the spec
about prohibiting SSLv2 then we'll convince more implementations to drop
support for it -- and that seems to be the right direction to go in.

FYI, in my working copy I currently have the following text:

***

13.8.  TLS Versions

   Implementations of TLS typically support multiple versions of the
   Transport Layer Security protocol as well as the older Secure Sockets
   Layer (SSL) protocol.  Because of known security vulnerabilities,
   XMPP servers and clients MUST NOT request or offer SSL 2.0, and MUST
   close the TCP connection if the other party to an XML stream requests
   or offers SSL 2.0.  See Appendix E.2 of [TLS] for further details.

***