Hi Peter, The new text address my comments, I just have a proposal on section 3.5 see inline Roni > -----Original Message----- > From: Peter Saint-Andre - &yet [mailto:peter@xxxxxxxxxx] > Sent: 03 April, 2015 7:34 PM > To: Roni Even; draft-ietf-uta-xmpp.all@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx; XMPP Working Group; uta@xxxxxxxx > Subject: Re: Gen-ART LC review of draft-ietf-uta-xmpp-05 > > Hi Roni, thanks for the review. > > On 4/3/15 3:59 AM, Roni Even wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-uta-xmpp-05 > > > > Reviewer: Roni Even > > > > Review Date:2015-4-3 > > > > IETF LC End Date: 2015-4-13 > > > > IESG Telechat date: > > > > Summary: This draft is not ready for publication as an Standard Track RFC. > > > > Major issues: > > > > I am wondering why this document is a standard track and not > > Informational, reading it I get the impression that it repeats text > > from > > RFC6120 and does not provide new normative information. > > Ah, I see the confusion. > > Earlier versions of this document repeated the recommendations from draft- > ietf-uta-tls-bcp and explicitly applied them to XMPP. At some point we > refactored the document so that it wasn't repeating the text (because that's > usually a bad idea - things can get out of sync etc.), but in the process we lost > those normative statements. > > To fix the problem, I suggest that we change the following paragraph and move > it to be the first paragraph of Section 3: > > OLD > NOTE: Unless explicitly noted otherwise, all of the > recommendations specified in [I-D.ietf-uta-tls-bcp] apply to XMPP. > In the main, this document merely provides supplementary > information; those who implement and deploy XMPP technologies are > expected to follow the recommendations of [I-D.ietf-uta-tls-bcp]. > > NEW > XMPP implementations and deployments MUST follow the > recommendations provided in [I-D.ietf-uta-tls-bcp] unless > explicitly noted otherwise herein. Instead of repeating those > recommendations here, this document mostly provides supplementary > regarding implementation and deployment of XMPP technologies. [Roni Even] This is clearer now > > > Section 3.1 talks about TLS support and say that it SHOULD be tried > > but since it is a SHOULD I assume that failure may happen and non TLS > > connections may be used ( I am not sure what RFC6120 say about it. > > Section 3.1 attempts to say this (but clearly we did not phrase things very well): > the lack of an indication that a connection endpoint supports TLS SHOULD NOT > prevent a connecting entity from attempting TLS negotiation. In fact, I think we > could say MUST NOT (the "SHOULD" comes from local policy). > > Therefore I suggest the following rewording: > > OLD > The server (i.e., the XMPP receiving entity) to which a client or > peer server (i.e., the XMPP initiating entity) connects might not > offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns > :xmpp-tls'/>. Although in general this stream feature indicates that > the server supports XMPP 1.0 and therefore supports TLS, it is > possible that this stream feature might be stripped out by an > attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]). Therefore, > the initiating entity SHOULD proceed with the stream negotiation even > if the receiving entity does not advertise support for TLS. > Similarly, although a receiving entity SHOULD include the <required/> > child element to indicate that negotiation of TLS is mandatory, an > initiating entity MUST NOT depend on receiving the <required/> flag > in determining whether TLS will be enforced for the stream. > > NEW > The server (i.e., the XMPP receiving entity) to which a client or > peer server (i.e., the XMPP initiating entity) connects might not > offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns > :xmpp-tls'/>. Although in general this stream feature indicates that > the server supports XMPP 1.0 and therefore supports TLS, it is > possible that this stream feature might be stripped out by an > attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]). > Similarly, the <required/> child element of the <starttls/> stream > feature is used to indicate that negotiation of TLS is mandatory, > but could also be stripped out by an attacker. Therefore, the > initiating entity MUST NOT be deterred from attempting TLS > negotiation even if the receiving entity does not advertise support > for TLS. Instead, the initiating entity SHOULD (based on local > policy) proceed with the stream negotiation and attempt to negotiate > TLS. [Roni Even] OK > > > Section 3.4 may look like authentication is a MUST but section 3.5 > > talks about unauthenticated connections > > Well, there are client-to-server connections and server-to-server connections in > XMPP. The former need to be authenticated and the latter do not (although we > are working on ways to make authentication easier and more pervasive for > server-to-server connections). I thought we had captured that in the text, but > perhaps not. [Roni Even] Maybe start section 3.5 saying that it is only about server to server connection, currently the end of the section says " this at least enables encryption of server-to-server connections." But I did not understand it as saying that this section is only about server to server connection. > > > On section 3.7 I assume that providing e2e information is based on the > > XMPP architecture that may have only one server to server hop. Are > > there other cases? > > In Section 3.7 we weren't trying to say that information can be provided about > the end-to-end encryption status of all the hops along a communications path > because that's impossible (at least in a way that can be trusted). We might > adjust the text to avoid any confusion, as > follows: > > OLD > o Determine if a client-to-server or server-to-server connection is > encrypted and authenticated. > o Determine the version of TLS used for a client-to-server or > server-to-server connection. > > NEW > o Determine if a given incoming or outgoing XML stream is > encrypted and authenticated using TLS. > o Determine the version of TLS used for a given stream. [Roni Even] OK > > Peter > > -- > Peter Saint-Andre > https://andyet.com/