Hi Stephen, thanks for the review and my apologies about the delayed reply.
On 3/28/15 9:30 AM, Stephen Farrell wrote:
Hiya, As your non-shiny new helper AD I've reviewed draft-ietf-uta-xmpp-05. I have some comments (below), none need hold up IETF LC I think so please treat these as you would IETF LC comments. I'll request IETF LC momentarily. Thanks, S. - 3.4: I'm not clear what the last paragraph is telling me. What should I do about that?
Some motivating and concluding text might be helpful, such as: OLD The Domain Name Associations (DNA) specification [I-D.ietf-xmpp-dna] describes a framework for XMPP server authentication methods, which include not only PKIX but also DNS-Based Authentication of Named Entities (DANE) as defined in [I-D.ietf-dane-srv] and PKIX over Secure HTTP (POSH) as defined in [I-D.ietf-xmpp-posh]. NEW In some scenarios such as multi-tenanted environments, it can be extremely difficult to obtain or deploy PKIX certificates with the proper Subject Alternative Names. To overcome that challenge, the Domain Name Associations (DNA) specification [I-D.ietf-xmpp-dna] describes a framework for XMPP server authentication methods, which include not only PKIX but also DNS-Based Authentication of Named Entities (DANE) as defined in [I-D.ietf-dane-srv] and PKIX over Secure HTTP (POSH) as defined in [I-D.ietf-xmpp-posh]. These methods can provide a basis for server identity verification when appropriate PKIX certificates cannot be obtained or deployed.
- 3.7: practically, is it feasible to provide a client with information about server-server uses of TLS? (And how many server-server TLS "hops" might there be?)
See my reply to Roni Even's Gen-ART review. It is *not* feasible (at least not in a way that would provide information the client could trust), and the text was unclear enough to cause confusion. I suggested alternative text in my reply to Roni.
- 3.7: Would it be sensible here to recommend that servers log information about the use of TLS so as to be able to spot e.g. that what used normally be sent over TLS, is now in clear? I'm not sure how feasible it would be to do that very well, but maybe we could give developers some hints here and see what they come up with?
It seems better to require the use of TLS and never allow cleartext connections.
- 5: Would it be worth noting there that this is not e2e (obvious I guess) but that that means that some gateways (e.g. to SIP) may mean that we even if we really get all hops protected, we may not be able to report on that?
This document does not cover gateways, nor does RFC 6120. IMHO text about gatewaying belongs the appropriate specifications. For example, there is text about it in RFC 7247 and in draft-ietf-stox-im.
nits: - 3.5: maybe s/passive eavesdropping/eavesdropping/ and a reference to RFC7258 might save someone the trouble about arguing that case in XMPP land later.
Good idea.
- ID nits has some reference version nits, it's fine to fix those next time some changes are needed.
Given the scope of changes occasioned by Roni's review, we'll need a revised I-D before IESG consideration.
Peter -- Peter Saint-Andre https://andyet.com/ _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
