Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xmpp-05
Peter Saint-Andre - &yet <peter@andyet.net> Fri, 03 April 2015 16:33 UTC
Return-Path: <peter@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF991ACD31 for <xmpp@ietfa.amsl.com>; Fri, 3 Apr 2015 09:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsqrCU7YlCET for <xmpp@ietfa.amsl.com>; Fri, 3 Apr 2015 09:33:41 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BD81ACD30 for <xmpp@ietf.org>; Fri, 3 Apr 2015 09:33:38 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so98190857igb.1 for <xmpp@ietf.org>; Fri, 03 Apr 2015 09:33:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DrsI+VRA8XujTgVOTfHnIX7SVt93lCje3XtGVpPTni8=; b=QK3FfhyyfHqddCw3e5c1oHMx7BRR4deEVoNUosSVifmOiLXSWYvDCilBL+rAVSA3ww TARX6BknjcK0OS4zVsYvx6qC9BN8RZBQjIQgpFSzs5rSJxumaS9So2BwczP+kQHV44ya L/d1xDRjVrM3q29iF6BSMVjmDCXov9m9uy4Ee/h8SKgjCOjKELZUUSPBYzD2RFEYer7C cnTak72y9dSO4EOC1F3UD22FX/OIJCmfsJb73KQtVIkjybtolohr5/WoAB7PIvMHVvQ2 3CLfrGKsI8g4JiMfnyQHrYZeD1u2lK4WVQaMWmg10505ex9Qmjw3Z6Jin88kNjF0hm+D S7HQ==
X-Gm-Message-State: ALoCoQlBb7S5+gFPPrJYcF7/NBF+X+dVGenQzrsJeM+5KuUwUFkJPslQMc4k3b45/XI2fm79zmP5
X-Received: by 10.107.136.158 with SMTP id s30mr5165653ioi.65.1428078818309; Fri, 03 Apr 2015 09:33:38 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id z7sm5768986iod.12.2015.04.03.09.33.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 09:33:37 -0700 (PDT)
Message-ID: <551EC0E0.3010003@andyet.net>
Date: Fri, 03 Apr 2015 10:33:36 -0600
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>, draft-ietf-uta-xmpp.all@tools.ietf.org
References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com>
In-Reply-To: <020b01d06df4$ed64fa10$c82eee30$@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/8MbeHdc2MGurHaWUwMMt2k2fB34>
Cc: "uta@ietf.org" <uta@ietf.org>, gen-art@ietf.org, ietf@ietf.org, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xmpp-05
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2015 16:33:43 -0000
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. > 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. > 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. > 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. Peter -- Peter Saint-Andre https://andyet.com/
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Roni Even
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Peter Saint-Andre - &yet
- Re: [xmpp] Gen-ART LC review of draft-ietf-uta-xm… Roni Even