Hiya, Those seem fine. I guess the best is to see out the IETF LC and then re-spin the I-D,
Thanks, S. On 03/04/15 21:05, Peter Saint-Andre - &yet wrote: > 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 > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
