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

"Barry Leiba" <barryleiba@computer.org> Mon, 20 April 2015 21:55 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150420215550.18824.74064.idtracker@ietfa.amsl.com>
Date: Mon, 20 Apr 2015 14:55:50 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/HJzaZGwySsdNOly0qM2NUUlO0fo>
Cc: uta-chairs@ietf.org, draft-ietf-uta-xmpp.ad@ietf.org, uta@ietf.org, draft-ietf-uta-xmpp@ietf.org, draft-ietf-uta-xmpp.shepherd@ietf.org, leifj@sunet.se
Subject: [Uta] Barry Leiba's Discuss on draft-ietf-uta-xmpp-06: (with DISCUSS and COMMENT)

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

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/



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


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

[Uta] Barry Leiba's Discuss on draft-ietf-uta-xmp… Barry Leiba