[Uta] Barry Leiba's Yes on draft-ietf-uta-xmpp-06: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-uta-xmpp-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/



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