Hi Barry, thanks for the review. Comments inline.
On 4/20/15 3:43 PM, Barry Leiba wrote:
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
Yes, that's more readable for sure!
-- 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).
At one point in the history of this document, we had separate bullet
lists for administrators and end users. There was so much overlap that
it was confusing. However, we might consider bringing that back.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
