Skip to main content

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

Yes

(Kathleen Moriarty)
(Stephen Farrell)

No Objection

(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Barry Leiba Former IESG member
(was Discuss, Yes) Yes
Yes (2015-04-20 for -06) Unknown
-- 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).
Ben Campbell Former IESG member
Yes
Yes (2015-04-21 for -06) Unknown
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?
Kathleen Moriarty Former IESG member
Yes
Yes (for -06) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2015-04-20 for -06) Unknown
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?
Stephen Farrell Former IESG member
Yes
Yes (for -06) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -06) Unknown