Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)
draft-ietf-uta-xmpp-07

[Ballot comment]
3.4, paragraph 3:

Would you offer different guidance about the multi-tenant problem if POSH and DNA were finished? I don't suggest delaying for that, even though they are both post-WGLC. But I wonder if there is something here we need to clean up after POSH and DNA are published?

Paragraph 4:

By "unauthenticated connections", I assume it means "unauthenticated TLS [or encrypted] connections". Is this correct?

[Ballot discuss]
I forgot to put this in on my first ballot:
You have a downref to RFC 4949, and it wasn't called out in the last call message.  We'll have to do a second last call in order to comply with RFC 3967 (BCP 97).

[Ballot comment]
-- Section 3.4 --

  Wherever possible, it is best to prefer authenticated connections
  (along with SASL [RFC4422]), as already stated in the core XMPP
  specification [RFC6120].  In particular, clients MUST authenticate
  servers and servers MUST authenticate clients.

How does "prefer" "whenever possible" match up with "MUST" and "MUST"?

Ah, I see; in the next paragraph, we have server-to-server authentication, which isn't a MUST.  Got it.  So, purely optional if you agree with me, but I'd find it less confusing like this:

NEW
  Wherever possible, it is best to prefer authenticated connections
  (along with SASL [RFC4422]), as already stated in the core XMPP
  specification [RFC6120].  In particular:
 
  * Clients MUST authenticate servers.
  * Servers MUST authenticate clients.
  * Servers SHOULD authenticate other servers.

  This document does not mandate that servers need to authenticate
  peer servers, although such authentication is strongly preferred.
  Unfortunately, [...etc...]
END

-- Section 3.6 --

I understand that, while most users won't understand it, there's value in trying to communicate to an end user that she is using a secure connection.

I am very skeptical that there's the slightest bit of value in giving end users information about the version of TLS used, the mechanism for verification, the details of the certs (if any), or the details of the cipher suite.  I'm certainly skeptical that making that available to end users should rise to the level of "strongly encouraged".  I'm not going to block anything with regard to this, but I see this as something you might strongly encourage be available to an administrator, but not to an end user (other than, perhaps, by enabling detailed logging through an advanced setting, then inspecting the logs).

[Ballot comment]
This is important work. Thank you for doing it.

I have a couple of points where I wasn't clear on the text, but they're nits.

I'm not quite sure what this text:

3.3.  Session Resumption

  In XMPP, TLS session resumption can be used in concert with the XMPP
  Stream Management extension; see [XEP-0198] for further details.
 
means in a major section called "Recommendations". Good idea? Bad idea? Doesn't matter? It depends?

I could read "can be used" as saying "it's physically possible", or "it's OK", so I thought I should ask. I'm fine with you not saying anything normative, but it seems like a thumbs up/down/sideways would be helpful, at a minimum.
 
In this text:

5.  Security Considerations

  The use of TLS can help limit the information available for
  correlation to the network and transport layer headers as opposed to
  the application layer. 
 
I'm guessing what "as opposed to" means. Is this saying

  The use of TLS can help limit the information available for
  correlation between the network and transport layer headers
  and the application layer. 
 
or something else?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-uta-xmpp-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG
(uta) to consider the following document:
- 'Use of Transport Layer Security (TLS) in the Extensible Messaging and
  Presence Protocol (XMPP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/ballot/


No IPR declarations have been submitted directly on this I-D.

ID nits says some references are out of date, we'll fix that as
we go.

Summary
=======

Shepherd: Leif Johansson
Responsible AD: Pete Resnick


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 document is intended for standards track.

Review and Consensus
====================

The document extends the UTA TLS BCP to cover XMPP specifics and as
such is comparatively less controversial but has still seen enough
review to determine consensus. The document has been last-called in
both the XMPP and UTA WGs.

The review has been mostly done by a small circle of interested
individuals.

Please consider a review by the XMPP directorate.

Intellectual Property
=====================

No issues

Other Issues
============

There are a bunch of outdated references in the nits but those are
easy to deal with before publication.

There is one normative reference to an informative RFC (RFC4949).

Both of these issues can be handled in the IESG queue.

Summary
=======

Shepherd: Leif Johansson
Responsible AD: Pete Resnik


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 document is intended for standards track.

Review and Consensus
====================

The document extends the UTA TLS BCP to cover XMPP specifics and as
such is comparatively less controversial but has still seen enough
review to determine consensus. The document has been last-called in
both the XMPP and UTA WGs.

The review has been mostly done by a small circle of interested
individuals.

Please consider a review by the XMPP directorate.

Intellectual Property
=====================

No issues

Other Issues
============

There are a bunch of outdated references in the nits but those are
easy to deal with before publication.

There is one normative reference to an informative RFC (RFC4949).

Both of these issues can be handled in the IESG queue.