Hi Ben, thanks for the review.
On 4/21/15 3:53 PM, Ben Campbell wrote:
Ben Campbell 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:
----------------------------------------------------------------------
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?
I think it's not a question of "published" but of "widely implemented
and deployed". Thus, unfortunately, I would not foresee being able to
absolutely mandate server-to-server authentication for at least a few
years. However, that is certainly the goal. Do you think that additional
text would be helpful here?
Paragraph 4:
By "unauthenticated connections", I assume it means "unauthenticated TLS
[or encrypted] connections". Is this correct?
Good point: I think it would be best to make the following change.
OLD
Given the pervasiveness of eavesdropping [RFC7258], even an
unauthenticated connection might be better than an unencrypted
connection in these scenarios (this is similar to the "better than
nothing security" approach for IPsec [RFC5386]). Unauthenticated
connections include connections negotiated using anonymous Diffie-
Hellman mechanisms or using self-signed certificates, among others.
In particular for XMPP server-to-server interactions, it can be
reasonable for XMPP server implementations to accept unauthenticated
but encrypted connections when Server Dialback keys [XEP-0220] are
used; such keys on their own provide only weak identity verification
(made stronger through the use of DNSSEC [RFC4033]), but this at
least enables encryption of server-to-server connections. The DNA
prooftypes described above are intended to mitigate the residual need
for unauthenticated connections in these scenarios.
NEW
Given the pervasiveness of eavesdropping [RFC7258], even an
encrypted but unauthenticated connection might be better than an
unencrypted connection in these scenarios (this is similar to the
"better than nothing security" approach for IPsec [RFC5386]).
Encrypted but unauthenticated connections include connections
negotiated using anonymous Diffie-Hellman mechanisms or using
self-signed certificates, among others. In particular for XMPP
server-to-server interactions, it can be reasonable for XMPP server
implementations to accept encrypted but unauthenticated connections
when Server Dialback keys [XEP-0220] are used; such keys on their
own provide only weak identity verification (made stronger through
the use of DNSSEC [RFC4033]), but this at least enables encryption
of server-to-server connections. The DNA prooftypes described above
are intended to mitigate the residual need for encrypted but
unauthenticated connections in these scenarios.
Rationale: the contrast is between (a) connections that are encrypted
but not authenticated and (b) connections that are both encrypted and
authenticated.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
