Subject: [xmpp] Fwd: I-D Action: draft-saintandre-xmpp-tls-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 10:35:08 -0600

FYI.

- -------- Original Message --------
Subject: I-D Action: draft-saintandre-xmpp-tls-00.txt
Date: Mon, 09 Sep 2013 09:32:08 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Use of Transport Layer Security (TLS) in the
Extensible Messaging and Presence Protocol (XMPP)
	Author(s)       : Peter Saint-Andre
	Filename        : draft-saintandre-xmpp-tls-00.txt
	Pages           : 6
	Date            : 2013-09-09

Abstract:
   This document provides recommendations for the use of Transport Layer
   Security (TLS) in the Extensible Messaging and Presence Protocol
   (XMPP).  This document updates RFC 6120.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-saintandre-xmpp-tls-00

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 10:42:17 -0600

Oh, I just thought of another open issue: we might want to say
something about TLS session resumption.

On 9/9/13 10:35 AM, Peter Saint-Andre wrote:
> FYI.
> 
> 
> -------- Original Message -------- Subject: I-D Action:
> draft-saintandre-xmpp-tls-00.txt Date: Mon, 09 Sep 2013 09:32:08
> -0700 From: [email-masked] Reply-To:
> [email-masked] To: [email-masked]
> 
> 
> Extensible Messaging and Presence Protocol (XMPP) Author(s)       :
> Peter Saint-Andre Filename        :
> draft-saintandre-xmpp-tls-00.txt Pages           : 6 Date
> : 2013-09-09
> 
> Abstract: This document provides recommendations for the use of
> Transport Layer Security (TLS) in the Extensible Messaging and
> Presence Protocol (XMPP).  This document updates RFC 6120.
> 
> 
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________ I-D-Announce
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
> directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> _______________________________________________ xmpp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
> 

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Sep 2013 17:51:44 +0100

> http://tools.ietf.org/html/draft-saintandre-xmpp-tls-00

Thanks for writing this, it looks like an excellent start.

    o  Add information about the rationale for each recommendation,
      perhaps in an appendix.

That seems reasonable, but I don't think there's a need to describe each
recommendation individually.

   o  Recommend a specific ciphersuite or a small number of
      ciphersuites?

Picking a small selection of SHOULD or MUST implement seems fair.

   o  Provide recommendations regarding key lengths?

I think you already do for ephemeral keys, but public key lengths yes.

   o  Discuss TLS compression vs. application-layer compression?

It's not obvious it's a security issue, but yes. The issue remains that
compressing streams takes a serious wodge of data, but it's desirable.

Also, I think we should discuss the use of anonymous (or unauthenticated in
general) TLS; I've been convinced recently that using even a
non-channel-binding authentication and unauthenticated TLS is substantially
better than nothing. It's also what the deployed base actually does.

Finally, I'd be keen to see this adopted by the working group if that's on
the table.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 11:08:05 -0600

On 9/9/13 10:51 AM, Dave Cridland wrote:
> On Mon, Sep 9, 2013 at 5:35 PM, Peter Saint-Andre
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

You inspired it because as I recall you suggested that we pull some of
the security recommendations out of draft-ietf-xmpp-3920bis and into a
separate spec that we could update more readily. :-)

> That seems reasonable, but I don't think there's a need to describe
> each recommendation individually.

Agreed, and the justification for some of them is already available
elsewhere. It seems that draft-sheffer-tls-bcp might evolve in that
direction, too.

> I think you already do for ephemeral keys, but public key lengths

I'm thinking of the discussion here:

http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html

> It's not obvious it's a security issue, but yes.

Well, there is the CRIME attack against some technologies that use TLS
compression, however it's not clear to me if that applies to XMPP.

> The issue remains that compressing streams takes a serious wodge of
> data, but it's desirable.
> 
> Also, I think we should discuss the use of anonymous (or
> unauthenticated in general) TLS; I've been convinced recently that
> using even a non-channel-binding authentication and unauthenticated
> TLS is substantially better than nothing. It's also what the
> deployed base actually does.

Could you explain a bit more what you mean by unauthenticated TLS?

> Finally, I'd be keen to see this adopted by the working group if
> that's on the table.

I leave that up to the chairs. :-)  Depending on how you read the
charter, it might or might not be in scope.

Peter

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 9 Sep 2013 17:08:43 +0000

Some initial feedback:

* Very nice start, and "YAY" for short and to-the-point drafts! (-:

* This document needs to include recommendations for STARTTLS.  Maybe start with something like "initiating entities MUST expect <starttls/> in the receiving entity's <stream:features/>, and MUST reject the connection if missing".

* In 4.1. Protocol Versions -- ought the document to also recommend that implementations support the latest version of TLS (which is currently 1.2)?  That might seem obvious ...

* In 4.2. Ciphersuites -- this ought to explicitly disallow the NULL ciphersuites.  Again, this might seem obvious ...

* Also in 4.2. Ciphersuites -- maybe include something about preferring suites that utilize authenticated encryption (e.g., AES-GCM).

On "Open Issues":

* Including rationales would be very helpful, and I think it best to include them as close to the recommendation text as possible.

* I think recommending a particular set of ciphersuites would be worthwhile.

* A minimum key length for public keys is definitely necessary.   It looks like the ephemeral keys already have minimum length recommendations.

* I think a discussion of TLS- versus application-layer compression is worthwhile.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On Sep 9, 2013, at 10:35 AM, Peter Saint-Andre <[email-masked]>
 wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> FYI.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSLfi8AAoJEOoGpJErxa2pTBwP/2wai24XXThd0la48PuZMKP1
> DYCClQzjvm/TOBdSk/EQxQlq50B3KEH3AN2WFN5a7f22GXT/44kZzMCi+maEiz+X
> FyazwluRPisP/LHcg+CIDZxcj0RJFVbBAClLUCYTNukmmd9gegCZnPRgWyDnOs7E
> Kus7OLp8FcKPIpq7dHB95Ya2jmGTNmC7VAk0ckPthuBy1Lg48LPfGL2olUckqT7c
> snRL8eCNvvGp2/QK3yvLcoUWnk/8IBDLoGvS1Yi/jEWrVGjVzAzl+zZK+g/7H0Bo
> pMYPwplFeIWmmTTf+sjTKJo1RzFtlaob86xA7ybuD+RpELgqHvM8MvS8rai/QmQL
> dElBQSd8SqoElmuJzT61R0A70JMmcnzLMC1H/3+J0Pbafy4c1H/WKghSH1+XAKVv
> mcRLuyFTi2heuXBVWcRr4rqL4mr9lrsztdFE7m5HEx6I7mTnLwFxgcdzLh+WPAkv
> wwP61eEU2w5kco/8yMM8d+iiyt9Q1rsz+YivG4a9Ilnq2Y2f/FLVu5ztAOesT2wS
> eEmNbKnFCzATwfj+h9x7BYVJdGdt3zR6iUwVuf7FBOjqN3Z2JXmC7KtQE4NUu4vd
> zcsAvACv5a+jpJd0/QNGiXXS8Fjn4LP/ols4n3AHScJPAjRmfVGqu2VkNRDxowYP
> 7Y++rCrAcvpGqarre6P0
> =9WO8
> -----END PGP SIGNATURE-----
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 09 Sep 2013 19:12:40 +0200

> Could you explain a bit more what you mean by unauthenticated TLS?

Using TLS without checking certificates. Think of the starttls+dialback 
stuff that some people have done for years.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 11:17:07 -0600

On 9/9/13 11:12 AM, Philipp Hancke wrote:
>>> unauthenticated in general) TLS; I've been convinced recently
>>> that using even a non-channel-binding authentication and
>>> unauthenticated TLS is substantially better than nothing. It's
>>> also what the deployed base actually does.
>> 
> Using TLS without checking certificates. Think of the
> starttls+dialback stuff that some people have done for years.

OK, just checking so that it's in the archives. It's basically the
same concept as "better than nothing security", right?

https://datatracker.ietf.org/doc/rfc5386/

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 11:21:54 -0600

> Picking a small selection of SHOULD or MUST implement seems fair.

BTW, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 seems to be something that
folks prefer for TLS 1.2, but we'll want to recommend something for
earlier versions of TLS, too.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 11:30:44 -0600

> * Very nice start, and "YAY" for short and to-the-point drafts!

Thanks!

> * This document needs to include recommendations for STARTTLS.
> Maybe start with something like "initiating entities MUST expect 
> <starttls/> in the receiving entity's <stream:features/>, and MUST 
> reject the connection if missing".

Yes, there's been related discussion on the DANE list recently (in
relation to IMAP).

> * In 4.1. Protocol Versions -- ought the document to also
> recommend that implementations support the latest version of TLS
> (which is currently 1.2)?  That might seem obvious ...

Good point. Work has started on TLS 1.3, although there's no I-D for
it AFAIK. If we publish a spec like this, I'd expect it to be updated
on a somewhat regular basis. But pointing to 1.2+ seems sensible.

> * In 4.2. Ciphersuites -- this ought to explicitly disallow the
> NULL ciphersuites.  Again, this might seem obvious ...

Nothing is obvious. :-) Will add.

> * Also in 4.2. Ciphersuites -- maybe include something about 
> preferring suites that utilize authenticated encryption (e.g., 
> AES-GCM).

Another good point.

> On "Open Issues":
> 
> * Including rationales would be very helpful, and I think it best
> to include them as close to the recommendation text as possible.

As long as the text doesn't get too wordy. Will experiment with that
in the nexst version.

> * A minimum key length for public keys is definitely necessary.
> It looks like the ephemeral keys already have minimum length 
> recommendations.
> 

Yep, agreed on those.

Thanks for the feedback. I expect to be submitting a revised I-D by the
end of the week.

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Sep 2013 18:33:54 +0100

> separate spec that we could update more readily. :-)
OK, I could take credit. Though years of management have trained me to wait
until I see a successful outcome first.

> compression, however it's not clear to me if that applies to XMPP.
Ah, that. Right.

> Could you explain a bit more what you mean by unauthenticated TLS?
Any TLS channel which is not authenticated; so ADH is anonymous, whereas
self-signed cert usage is the (broader) unauthenticated TLS, as are various
other cases.

> charter, it might or might not be in scope.
Charters can be changed, of course.

Dave.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Sep 2013 09:37:22 +0200

This feels like a good move. I would like to steal these ideas for SIP.
Now, the question is how we can get developers to listen?

/O

9 sep 2013 kl. 18:42 skrev Peter Saint-Andre <[email-masked]>:

> iQIcBAEBAgAGBQJSLfppAAoJEOoGpJErxa2pT7UQAIPcg6lmhdCJxoUuQilk5iFv
> DyxhX4UNWIkPCLEBWncjzA31vaihOWzdnS5KEqrtXWTWx4UTbe8PNMW+je3/sw9z
> FxKNLEC0k/DMq+KQ5503UnCT3TPToo3+WkCCjmpjBEEbaWkgJOm2Xow8mkU9n1+U
> +q6akKYbIBezZhKdYl5LKbLqff4U3Q/QWlBI/oAr8JgEckZgV8lJ9VZw4cQsSqa/
> HFmEwRghWEY75Wosj8mHvuD4GkBvWEx/fqI6wjCfTyLllM25mgATp/KonMuKJ1jC
> Sk57GVh8Zhlwjgu2Dem8OTL9BiVPrPJ+l+uMmK6ZMUcztxN0VL+Mwx3RXZxiX6Ho
> ZQXGWgXnk7/hcXak91qINl363ys+XayR4QtUJEIeB47tklI6Xlswy4+GsHzx69p7
> m3u7SV6i3dhWKYgvdksbLYjxBKSz0QUYMgmiZR+GjMj3j+KrSSerNx6yx9QkjtcM
> spWxRWzJN6j54BSw9hZpl9rTutVZNFaXGYdCUTI36awer4orzD4SXdsp4azZvbBT
> djSpGXEzd1ScHmaQnZ59slVOcDAZOkl3Ws+hWUZ+A6rFkeumzuo4V1vMbHQATa50
> xcE/jaDj0FcA9lzdMSNxs72YOo6e1swhbQ+fTTWkDwM6dRV949cHAOpeVwIUnYcQ
> KAAlZGZswWwG//t+GdyK
> =oufx

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Sep 2013 09:41:17 +0200

I notice that you do not mention SNI. Should that be added to server requirements. If not, why?

/O

---

---

From: Tobias Markmann <[email-masked]>
Date: Wed, 11 Sep 2013 09:51:29 +0200

Fwd. Forgot to hit Reply-All.

> requirements. If not, why?

SNI = Server Name Indication? If so, it isn't used by XMPP due to its use
of STARTTLS and by that servers knowing beforehand for what domain they
need to provide the certificate. Would it provide any value in STARTTLS
scenarios?

Cheers,
Tobi

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Sep 2013 09:55:24 +0200

11 sep 2013 kl. 09:51 skrev Tobias Markmann <[email-masked]>:

> SNI = Server Name Indication? If so, it isn't used by XMPP due to its use of STARTTLS and by that servers knowing beforehand for what domain they need to provide the certificate. Would it provide any value in STARTTLS scenarios?
> 
Right. Thanks for the response.

Personally I don't see any benefit of SNI in the case of STARTTLS. Anyone else?

/O

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 11 Sep 2013 10:01:26 +0200 (CEST)

> Personally I don't see any benefit of SNI in the case of STARTTLS. Anyone else?

No, and ISTR that it was removed in a late 3920bis draft for that reason.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Sep 2013 06:24:38 -0600

On 9/11/13 1:51 AM, Tobias Markmann wrote:
> On Wed, Sep 11, 2013 at 9:41 AM, Olle E. Johansson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> SNI = Server Name Indication? If so, it isn't used by XMPP due to
> its use of STARTTLS and by that servers knowing beforehand for what
> domain they need to provide the certificate. Would it provide any
> value in STARTTLS scenarios?

Right, we use the 'to' address of the initial stream header as
equivalent to SNI. This is mentioned in Section 4.7.2 of RFC 6120.

Peter

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

---

From: Thijs Alkemade <[email-masked]>
Date: Wed, 11 Sep 2013 14:47:20 +0200

Hello Peter,

Thank you for writing this. I think it's a good initiative and I hope many
servers start following it. Two things I want to note though:

* 3DES is technically 168 bit, but offers only 112 bits of security. As it is
  written, it does not fall under the MUST NOT for <128 bit algorithms. In my
  opinion it should be a MUST NOT too.

* If you follow the OpenSSL naming, I think you mean the ECDHE suites, not
  ECDH. ECDH does not offer forward secrecy.

Regards,
Thijs

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Sep 2013 09:25:03 -0600

Hallo Thijs!

On 9/11/13 6:47 AM, Thijs Alkemade wrote:
> Hello Peter,
> 
> Thank you for writing this. I think it's a good initiative and I
> hope many servers start following it. Two things I want to note
> though:
> 
> * 3DES is technically 168 bit, but offers only 112 bits of
> security. As it is written, it does not fall under the MUST NOT for
> <128 bit algorithms. In my opinion it should be a MUST NOT too.
> 
> * If you follow the OpenSSL naming, I think you mean the ECDHE
> suites, not ECDH. ECDH does not offer forward secrecy.

You are right on both counts. I'll fix those errors in the next
version. As to the first point, I'll change the text to talk about
bits of security, not the bit-size of the keys.

Peter

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