From nobody Wed Apr 1 09:51:54 2015 Return-Path: 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 AD2051AD16B for ; Wed, 1 Apr 2015 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 v3F1Mo0xpxH7 for ; Wed, 1 Apr 2015 09:51:48 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 B0E231ACEC2 for ; Wed, 1 Apr 2015 09:51:48 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so3347098obb.2 for ; Wed, 01 Apr 2015 09:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UTAMcFKUMrZqB1wgogbzqO87SqGUfbf5VVsMm50aHbI=; b=euX8IdYUW0iFk0snHjblVREWNN8xvSR7E/mjNZMvmAtu5U0sDAquXtX6MHbxSntTtg knU+6ELqmaIgymC+ncsMiz0Ka4XCecuViqb8chpi0V7aH2cCXWLbBqVkXH1XMXu8d+zk EabR4HNPfcyh/cgLFcQLtQQkyRyuwlmi5SGdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UTAMcFKUMrZqB1wgogbzqO87SqGUfbf5VVsMm50aHbI=; b=I40BzjS2s0+Pg/nSdzrbS5ACQvCrKqNHb5wZkL8leXv3wci/nypVGFd/87uB6jOhPj cv+ZWMYf452g5gBr/EokQG6SqGdaXpGbKCWGclvE0w3TZy2XJn0/XPCAtSj0ctfzzhK3 UWkkg1kZ1QzUC1iMhVEvp3EsO7tXU9Kk5+6CJw6xfJ7H8GY8YTaXWP0q38odNGAUFIgc jzFlZH26hjA4OUNC3aYgo/cZeB8SEWPzyHH9s3CNt67N7CpfSty3X1kA+2KQ6SpFD+/B xRWRaxrJdKPHyyCB2UEBMPFXvixqEVjFikOpOV+QD3nuhYgeqA0RFemjseq8efSAEK8S r8Mg== X-Gm-Message-State: ALoCoQmSxQfFyl1Jg+uA5CV42bpdUZ5W4A32+mOoFGsRQfqA+vIiqvO5hq1rB2mMc71A9I7V8e2+ MIME-Version: 1.0 X-Received: by 10.182.88.136 with SMTP id bg8mr41760496obb.86.1427907106692; Wed, 01 Apr 2015 09:51:46 -0700 (PDT) Received: by 10.60.119.73 with HTTP; Wed, 1 Apr 2015 09:51:46 -0700 (PDT) In-Reply-To: <55118861.5060309@cisco.com> References: <20150324155049.5707.52124.idtracker@ietfa.amsl.com> <55118861.5060309@cisco.com> Date: Wed, 1 Apr 2015 17:51:46 +0100 Message-ID: From: Dave Cridland To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= Content-Type: multipart/alternative; boundary=089e0111bd76de19070512ac875e Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-10.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:51:50 -0000 --089e0111bd76de19070512ac875e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This revision addresses all my comments. On 24 March 2015 at 15:53, =E2=8C=98 Matt Miller wrote= : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > This revision should address all of the feedback we've received. > Thanks again everyone! > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > On 3/24/15 10:50 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Extensible Messaging > > and Presence Protocol Working Group of the IETF. > > > > Title : Domain Name Associations (DNA) in the Extensible > > Messaging and Presence Protocol (XMPP) Authors : Peter > > Saint-Andre Matthew Miller Philipp Hancke Filename : > > draft-ietf-xmpp-dna-10.txt Pages : 20 Date : > > 2015-03-24 > > > > Abstract: This document improves the security of the Extensible > > Messaging and Presence Protocol (XMPP) in two ways. First, it > > specifies how to establish a strong association between a domain > > name and an XML stream, using the concept of "prooftypes". Second, > > it describes how to securely delegate a service domain name (e.g., > > example.com) to a target server host name (e.g., > > hosting.example.net), which is especially important in > > multi-tenanted environments where the same target server hosts a > > large number of domains. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-xmpp-dna-10 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-dna-10 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ I-D-Announce > > mailing list I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > > directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJVEYhhAAoJEDWi+S0W7cO1nNwH/2anIXSxbozOeKbWwzjWhsMB > BqBluH07sN1tBkcMcRRn28EyZaMZAqMIt01EMdNzdE5XXA4zX+54OY5FEewJFTYm > XqK9d6pLEer60QbRNxNnOjTzDm9q3+vMBAQuGjjXupjLrSc258fRiOyiOSzqqcYC > WVJt/CoXdxCaWdX+VmATcKbD0wwLIjkYRxD00K46YKP8lxkUg9OZHCsF+57eDP+C > xx2o6SBL+k7wWDZPpP3OES2SwO7H6k7yoDetgzioNA6fInqrJliaZe2+xJhANcBu > t1oHQmq2rh8LSSb8Lzj4hLmWwbx9vt9npOTvQX945M2w7TZ+JCfWA+IkLHLSjYU=3D > =3Dst6V > -----END PGP SIGNATURE----- > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --089e0111bd76de19070512ac875e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This revision addresses all my comments.

On 24 March 2015 at 15:53, = =E2=8C=98 Matt Miller <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This revision should address all of the feedback we've received.
Thanks again everyone!


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.
On 3/24/15 10:50 AM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Extensible Messaging
> and Presence Protocol Working Group of the IETF.
>
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Domain Name Associatio= ns (DNA) in the Extensible
> Messaging and Presence Protocol (XMPP) Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Peter
> Saint-Andre Matthew Miller Philipp Hancke Filename=C2=A0 =C2=A0 =C2=A0= =C2=A0 :
> draft-ietf-xmpp-dna-10.txt Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 20 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
> 2015-03-24
>
> Abstract: This document improves the security of the Extensible
> Messaging and Presence Protocol (XMPP) in two ways.=C2=A0 First, it > specifies how to establish a strong association between a domain
> name and an XML stream, using the concept of "prooftypes".= =C2=A0 Second,
> it describes how to securely delegate a service domain name (e.g.,
> example.com) to a= target server host name (e.g.,
> hosting.examp= le.net), which is especially important in
> multi-tenanted environments where the same target server hosts a
> large number of domains.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-xmpp-dna-10
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-dna-10=
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org= .
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________ I-D-Announ= ce
> mailing list I-D-Announce@iet= f.org
> https://www.ietf.org/mailman/listinfo/i-d-announce Internet= -Draft
> directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org

iQEcBAEBCgAGBQJVEYhhAAoJEDWi+S0W7cO1nNwH/2anIXSxbozOeKbWwzjWhsMB
BqBluH07sN1tBkcMcRRn28EyZaMZAqMIt01EMdNzdE5XXA4zX+54OY5FEewJFTYm
XqK9d6pLEer60QbRNxNnOjTzDm9q3+vMBAQuGjjXupjLrSc258fRiOyiOSzqqcYC
WVJt/CoXdxCaWdX+VmATcKbD0wwLIjkYRxD00K46YKP8lxkUg9OZHCsF+57eDP+C
xx2o6SBL+k7wWDZPpP3OES2SwO7H6k7yoDetgzioNA6fInqrJliaZe2+xJhANcBu
t1oHQmq2rh8LSSb8Lzj4hLmWwbx9vt9npOTvQX945M2w7TZ+JCfWA+IkLHLSjYU=3D
=3Dst6V
-----END PGP SIGNATURE-----

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--089e0111bd76de19070512ac875e-- From nobody Fri Apr 3 09:33:52 2015 Return-Path: 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 ; 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 ; 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 ; Fri, 3 Apr 2015 09:33:38 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so98190857igb.1 for ; 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 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 , 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: Cc: "uta@ietf.org" , gen-art@ietf.org, ietf@ietf.org, XMPP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > . > > 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 . 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 child element to indicate that negotiation of TLS is mandatory, an initiating entity MUST NOT depend on receiving the 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 . 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 child element of the 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/ From nobody Fri Apr 3 13:50:00 2015 Return-Path: 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 992711A0158; Fri, 3 Apr 2015 13:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OGsM4qC8jX5V; Fri, 3 Apr 2015 13:47:47 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 B06091A0115; Fri, 3 Apr 2015 13:47:46 -0700 (PDT) Received: by wiun10 with SMTP id n10so4131627wiu.1; Fri, 03 Apr 2015 13:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=o0ygZeWMlXWjPaEahiZPV7dY4PHH25x5EYxuFqS+eIc=; b=s/hDtmh+ghij+CA+qR55ST720N6sWzx0lwc9Zxlmoq1n3Y6HQHlhLbLGF/ok7roxdw KUX9dsy0R1fRPSkhbEI4n+j2AXdR2f3UuG8Pkfde/YHYGi/bNM/IgPCksm+2hPpgFbkZ MKnlTUQAHlCnmUxXfCNHqBl24TjEYuH57js6UEC7S39RZIMWu4v271/gCCx/IIPrEInI sC41OpacQVVJvt0hLA1mZ9zBNM/92yWKh9v1a3Nvy8VG8nNUKk+rNa/RTpgmLpCIQstm /vDnIXrwYlMsN8j9/ZGNMTYV+FiGqWSHKCKuzUIcmxoKJYuRvD5G7dq6jBBArZl3H8KS KJ1A== X-Received: by 10.180.11.144 with SMTP id q16mr37775724wib.28.1428094065424; Fri, 03 Apr 2015 13:47:45 -0700 (PDT) Received: from RoniE (bzq-79-177-166-235.red.bezeqint.net. [79.177.166.235]) by mx.google.com with ESMTPSA id nh6sm3288524wic.1.2015.04.03.13.47.42 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Apr 2015 13:47:44 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre - &yet'" , References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com> <551EC0E0.3010003@andyet.net> In-Reply-To: <551EC0E0.3010003@andyet.net> Date: Fri, 3 Apr 2015 23:47:37 +0300 Message-ID: <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJMf+mV10+6viYGXJ9VPRCzfMuAZQKfVnJAnC6hneA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Fri, 03 Apr 2015 13:50:00 -0700 Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:47:49 -0000 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@andyet.net] > Sent: 03 April, 2015 7:34 PM > To: Roni Even; draft-ietf-uta-xmpp.all@tools.ietf.org > Cc: gen-art@ietf.org; ietf@ietf.org; XMPP Working Group; uta@ietf.org > 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 > > . > > > > 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 . 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 > child element to indicate that negotiation of TLS is mandatory, an > initiating entity MUST NOT depend on receiving the 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 . 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 child element of the 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/ From nobody Fri Apr 3 14:08:34 2015 Return-Path: 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 291871A19F2 for ; Fri, 3 Apr 2015 14:08:30 -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 ya0lc8zqpUbS for ; Fri, 3 Apr 2015 14:08:28 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (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 D51DF1A1B8E for ; Fri, 3 Apr 2015 14:08:26 -0700 (PDT) Received: by igcau2 with SMTP id au2so70623443igc.1 for ; Fri, 03 Apr 2015 14:08:26 -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=IpIoN/xVlLRFqnX4ym7cwiGou/io8TgjAezWcbzvcpU=; b=eo5YJd0oXNJ/7Ae3U2E+TuSzzjNG+WqhsOwjIiEwGIKqokItMm54PtKKSQShiOSVdJ ySYjWV5ETHc/TVI9cBFmmjpAgojT06l803CrtnwA6XUZkq+bNVWB8IJZk0Yd0SPATvfm pskBmWb/sJ+MzRhuof+CA3DisS2Z66kU2b7q5UmWbGf5NimWO6iT3MsFN+YCkiyIeWWr Np1lJt8NbZ4UOM7slP3rUcYgTw64kAdzQSJbcu35eDiiWnkZDLJvIRFhYzVHCRyK5n4N labSxP0m9tGTL+lhEO9qLzQic6uvrjrrGsFZHXCo8ahecqeEDCeacUKS0HN9W5Vw2TfN tPOw== X-Gm-Message-State: ALoCoQlzald9cShsvTbRwkQrjMxoDtJj3r7iSqcKDgY2AABNI9tQGYl+8rmx/zT7DNt1ng6IgCIM X-Received: by 10.42.79.204 with SMTP id s12mr6290920ick.78.1428095306362; Fri, 03 Apr 2015 14:08:26 -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 i80sm6251454iod.6.2015.04.03.14.08.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 14:08:25 -0700 (PDT) Message-ID: <551F0148.30000@andyet.net> Date: Fri, 03 Apr 2015 15:08:24 -0600 From: Peter Saint-Andre - &yet 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 , draft-ietf-uta-xmpp.all@tools.ietf.org References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com> <551EC0E0.3010003@andyet.net> <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> In-Reply-To: <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:08:30 -0000 On 4/3/15 2:47 PM, Roni Even wrote: > Hi Peter, > The new text address my comments, I just have a proposal on section 3.5 see > inline >>> 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. Well, it *mostly* applies to server-to-server connections (there are cases with multi-tenanted environments where something like DANE also helps for client-to-server connections). The whole topic is messy on the client side because of bad user habits about click-through security, trust on first use, overriding defaults, etc. Here is a proposed change. OLD Given the pervasiveness of passive eavesdropping, even an unauthenticated connection might be better than an unencrypted connection (this is similar to the "better than nothing security" approach for IPsec [RFC5386]). Unauthenticated connections include connections negotiated using anonymous Diffie-Hellman algorithms or using self-signed certificates, among other scenarios. In particular, because of current deployment challenges for authenticated connections between XMPP servers (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details), it can be reasonable for XMPP server implementations to accept unauthenticated connections when Server Dialback keys [XEP-0220] are used; although such keys on their own provide only weak identity verification (made stronger through the use of DNSSEC [RFC4033]), this at least enables encryption of server-to-server connections. NEW Although as just described authentication of the receiving entity is either mandatory (for client-to-server connections) or strongly preferred (for server-to-server connections), given the pervasiveness of eavesdropping [RFC7258] even an unauthenticated connection might be better than an unencrypted connection (this is similar to the "better than nothing security" approach for IPsec [RFC5386]). Unauthenticated connections include connections negotiated using anonymous Diffie-Hellman algorithms or using self-signed certificates, among other scenarios. At present there are deployment challenges for authenticated connections between XMPP servers, especially in multi-tenanted environments (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details). In some of these scenarios, 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 Domain Name Associations (DNA) prooftypes described in the previous section are intended to mitigate the residual need for unauthenticated connections in these scenarios. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Apr 3 14:33:17 2015 Return-Path: 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 6BAB71A1A8C for ; Fri, 3 Apr 2015 14:33:14 -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 mpUmMFhoLyXc for ; Fri, 3 Apr 2015 14:33:12 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 074A91A1A76 for ; Fri, 3 Apr 2015 14:33:12 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so102430862igb.1 for ; Fri, 03 Apr 2015 14:33:11 -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=ZM2JTSO6CYXC0ApWveV7ioibpzSfCtggAW+/Ex6/sds=; b=Bq14DY5Le8Xza2xoQs49jeEteQGVTgPDXL4XvpDYu+GMiwIlzKDlfBQ5KXSdXk+sFX KzppztovUfu+VOg7FSecfnrIA4yJqlNXigsSbM+t2/5gSBVIH2fvB/CUil3bKSjbUGvr Tom6JQsOtGBwao6ZucehuMh3+z/junwedHPy/GoXt99GLAiAOE9w0/2iLzjOWP6BXs/Q ETfHVYnLgtGiBp+riurqtNrXD/HqelMrO59rsRLQFvQHkWYeaeGV+xUMAjC64Xi1L/b3 KKUS24k+DunnKgKfSgI8PmXfrwtgVRa81COROb3ZQdBgLrAg9xIjERH5TX2Jb20BZaid 6WnQ== X-Gm-Message-State: ALoCoQm7Pmn+El4FPG3e0Zkjk5CRsdVNmIxocXhNWlRHdiX35fOQgB0BQnH97U78Yi0RBPpI7AzB X-Received: by 10.107.39.72 with SMTP id n69mr6602443ion.8.1428096791489; Fri, 03 Apr 2015 14:33:11 -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 h15sm6282963ioh.27.2015.04.03.14.33.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 14:33:10 -0700 (PDT) Message-ID: <551F0715.2030504@andyet.net> Date: Fri, 03 Apr 2015 15:33:09 -0600 From: Peter Saint-Andre - &yet 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 , draft-ietf-uta-xmpp.all@tools.ietf.org References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com> <551EC0E0.3010003@andyet.net> <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> <551F0148.30000@andyet.net> In-Reply-To: <551F0148.30000@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:33:14 -0000 On 4/3/15 3:08 PM, Peter Saint-Andre - &yet wrote: > On 4/3/15 2:47 PM, Roni Even wrote: >> Hi Peter, >> The new text address my comments, I just have a proposal on section >> 3.5 see >> inline > > > >>>> 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. > > Well, it *mostly* applies to server-to-server connections (there are > cases with multi-tenanted environments where something like DANE also > helps for client-to-server connections). The whole topic is messy on the > client side because of bad user habits about click-through security, > trust on first use, overriding defaults, etc. Here is a proposed change. > > OLD > Given the pervasiveness of passive eavesdropping, even an > unauthenticated connection might be better than an unencrypted > connection (this is similar to the "better than nothing security" > approach for IPsec [RFC5386]). Unauthenticated connections include > connections negotiated using anonymous Diffie-Hellman algorithms or > using self-signed certificates, among other scenarios. In > particular, because of current deployment challenges for > authenticated connections between XMPP servers (see > [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details), it can be > reasonable for XMPP server implementations to accept unauthenticated > connections when Server Dialback keys [XEP-0220] are used; although > such keys on their own provide only weak identity verification (made > stronger through the use of DNSSEC [RFC4033]), this at least enables > encryption of server-to-server connections. > > NEW > Although as just described authentication of the receiving entity is > either mandatory (for client-to-server connections) or strongly > preferred (for server-to-server connections), given the pervasiveness > of eavesdropping [RFC7258] even an unauthenticated connection might > be better than an unencrypted connection (this is similar to the > "better than nothing security" approach for IPsec [RFC5386]). > Unauthenticated connections include connections negotiated using > anonymous Diffie-Hellman algorithms or using self-signed > certificates, among other scenarios. > > At present there are deployment challenges for authenticated > connections between XMPP servers, especially in multi-tenanted > environments (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for > details). In some of these scenarios, 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 Domain Name > Associations (DNA) prooftypes described in the previous section are > intended to mitigate the residual need for unauthenticated > connections in these scenarios. I don't think that text is quite right. I suggest that we merge the sections on Authenticated Connections and Unauthenticated Connections, as follows: 3.4. Authenticated Connections Both the core XMPP specification [RFC6120] and the "CertID" specification [RFC6125] provide recommendations and requirements for certificate validation in the context of authenticated connections. This document does not supersede those specifications (e.g., it does not modify the recommendations in [RFC6120] regarding the Subject Alternative Names or other certificate details that need to be supported for authentication of XMPP connections using PKIX certificates). Wherever possible, it is best to prefer authenticated connections (along with SASL [RFC4422]), as already stated in the core XMPP specification [RFC6120]. In particular, clients MUST authenticate servers and servers MUST authenticate clients. This document does not mandate that servers need to authenticate peer servers, although such authentication is strongly preferred and servers SHOULD authenticate each other. Unfortunately, in multi- tenanted environments it can be extremely difficult to obtain or deploy PKIX certificates with the proper Subject Alternative Names (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details). To overcome that difficulty, 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. 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 algorithms 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 Domain Name Associations (DNA) prooftypes described above are intended to mitigate the residual need for unauthenticated connections in these scenarios. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sat Apr 11 09:27:33 2015 Return-Path: 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 B079B1A90B9; Fri, 3 Apr 2015 23:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8mUMa6CtXCKf; Fri, 3 Apr 2015 23:31:08 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 2A52B1A90B6; Fri, 3 Apr 2015 23:31:08 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so125186659wgb.1; Fri, 03 Apr 2015 23:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=3vIWRi2vhzhZPbb2TIU8iYyg5kNn1QgbHVebCLOLsSE=; b=YboN127OiPC0n0Es3Sj9d5JM8IvPKPHFIZgsHNrS+GjpS2A0Cnvus6+WtR0WiMWyX/ RDbio2knryJTbmAvmYNhmnBom7ScP2EU3Kd0hEQuaS6zB7wxVjcD87vJzsm2f/kS2pcE 4Sv37DJC7Bn4cJWvvKxCXNZZcsnwA6ICjh6x8oZQImwmCEC/nsfNU3pytkeqLM4BPV99 ppvXZxS47MNRde7HhILSszKAjd/yKBlLjS111BKIRYJowK7iLo2d+3WxkewOdeaEIVY2 zR58rE2sRaxkYz9MuHZUjH9Ysy6rxaPjzza+hmZH+Gj1h5Xp4wtQpqOTs1zSQ/x7jrTV gpfA== X-Received: by 10.194.20.67 with SMTP id l3mr11199346wje.94.1428129066940; Fri, 03 Apr 2015 23:31:06 -0700 (PDT) Received: from RoniE (bzq-79-177-166-235.red.bezeqint.net. [79.177.166.235]) by mx.google.com with ESMTPSA id ha10sm14339982wjc.37.2015.04.03.23.31.04 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Apr 2015 23:31:06 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre - &yet'" , References: <020b01d06df4$ed64fa10$c82eee30$@gmail.com> <551EC0E0.3010003@andyet.net> <024501d06e4f$6d983df0$48c8b9d0$@gmail.com> <551F0148.30000@andyet.net> <551F0715.2030504@andyet.net> In-Reply-To: <551F0715.2030504@andyet.net> Date: Sat, 4 Apr 2015 09:30:58 +0300 Message-ID: <025b01d06ea0$ec061a30$c4124e90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJMf+mV10+6viYGXJ9VPRCzfMuAZQKfVnJAAyJyA8gBzZaSIgH3TDSdm/gMhMA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 09:27:32 -0700 Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 06:31:10 -0000 Hi Peter, This text looks good Thanks Roni > -----Original Message----- > From: Peter Saint-Andre - &yet [mailto:peter@andyet.net] > Sent: 04 April, 2015 12:33 AM > To: Roni Even; draft-ietf-uta-xmpp.all@tools.ietf.org > Cc: gen-art@ietf.org; ietf@ietf.org; 'XMPP Working Group'; uta@ietf.org > Subject: Re: Gen-ART LC review of draft-ietf-uta-xmpp-05 > > On 4/3/15 3:08 PM, Peter Saint-Andre - &yet wrote: > > On 4/3/15 2:47 PM, Roni Even wrote: > >> Hi Peter, > >> The new text address my comments, I just have a proposal on section > >> 3.5 see > >> inline > > > > > > > >>>> 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. > > > > Well, it *mostly* applies to server-to-server connections (there are > > cases with multi-tenanted environments where something like DANE also > > helps for client-to-server connections). The whole topic is messy on > > the client side because of bad user habits about click-through > > security, trust on first use, overriding defaults, etc. Here is a proposed > change. > > > > OLD > > Given the pervasiveness of passive eavesdropping, even an > > unauthenticated connection might be better than an unencrypted > > connection (this is similar to the "better than nothing security" > > approach for IPsec [RFC5386]). Unauthenticated connections include > > connections negotiated using anonymous Diffie-Hellman algorithms or > > using self-signed certificates, among other scenarios. In > > particular, because of current deployment challenges for > > authenticated connections between XMPP servers (see > > [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details), it can be > > reasonable for XMPP server implementations to accept unauthenticated > > connections when Server Dialback keys [XEP-0220] are used; although > > such keys on their own provide only weak identity verification (made > > stronger through the use of DNSSEC [RFC4033]), this at least enables > > encryption of server-to-server connections. > > > > NEW > > Although as just described authentication of the receiving entity is > > either mandatory (for client-to-server connections) or strongly > > preferred (for server-to-server connections), given the pervasiveness > > of eavesdropping [RFC7258] even an unauthenticated connection might > > be better than an unencrypted connection (this is similar to the > > "better than nothing security" approach for IPsec [RFC5386]). > > Unauthenticated connections include connections negotiated using > > anonymous Diffie-Hellman algorithms or using self-signed > > certificates, among other scenarios. > > > > At present there are deployment challenges for authenticated > > connections between XMPP servers, especially in multi-tenanted > > environments (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for > > details). In some of these scenarios, 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 Domain Name > > Associations (DNA) prooftypes described in the previous section are > > intended to mitigate the residual need for unauthenticated > > connections in these scenarios. > > I don't think that text is quite right. I suggest that we merge the sections on > Authenticated Connections and Unauthenticated Connections, as follows: > > 3.4. Authenticated Connections > > Both the core XMPP specification [RFC6120] and the "CertID" > specification [RFC6125] provide recommendations and requirements for > certificate validation in the context of authenticated connections. > This document does not supersede those specifications (e.g., it does > not modify the recommendations in [RFC6120] regarding the Subject > Alternative Names or other certificate details that need to be > supported for authentication of XMPP connections using PKIX > certificates). > > Wherever possible, it is best to prefer authenticated connections > (along with SASL [RFC4422]), as already stated in the core XMPP > specification [RFC6120]. In particular, clients MUST authenticate > servers and servers MUST authenticate clients. > > This document does not mandate that servers need to authenticate peer > servers, although such authentication is strongly preferred and > servers SHOULD authenticate each other. Unfortunately, in multi- > tenanted environments it can be extremely difficult to obtain or > deploy PKIX certificates with the proper Subject Alternative Names > (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details). To > overcome that difficulty, 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. > > 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 algorithms 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 Domain > Name Associations (DNA) prooftypes described above are intended to > mitigate the residual need for unauthenticated connections in these > scenarios. > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ From nobody Mon Apr 27 12:28:39 2015 Return-Path: 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 467DA1ACD40 for ; Mon, 27 Apr 2015 12:28:38 -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=ham 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 2QymJjf-7iLK for ; Mon, 27 Apr 2015 12:28:36 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (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 8ECF21ACD17 for ; Mon, 27 Apr 2015 12:28:36 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so2391339ied.1 for ; Mon, 27 Apr 2015 12:28:35 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GkYTUc924KB6B6vnXtGnaXmCGGpSw9QXo/RbMT/ekSY=; b=TXGJQ7rT9c21WfWrO2uhnJIB9NomvFIn/RxWWHNwBp19DfWWgP8HXPcScgw82FfPsq ybD9eu7I4O4bcHh6YVfOSCpzcE9JEg5lAqyQA+/OoG0ilLH2oeLFKofFiIhGBNnEStYw HrubL6ihTqQwvbb5rGgbqDynnVzHfMnZ94rzrKLd6LMxprJ9z+y2zIkgo7tO9m7nTC44 /JP7sQJivjM15fXOtIt65h6rlmMra+RZ/rZhuUTiD05DAME6Uo46qww61uCCiwKiZBTe NsiPSN+ZDruWOYukFm2Fv19NA+Z6UHQko4+hPOf/okmGzFnoyqu1oVIPTwEQEVxAV5fD irbA== X-Gm-Message-State: ALoCoQkYm1hl8lKQrTx8MD2eGDQmRyzPf0O8PNTdKq/c7hii5jkhEdfQvSOIPJH/RsUPLj843SFW X-Received: by 10.107.154.70 with SMTP id c67mr15812466ioe.22.1430162915868; Mon, 27 Apr 2015 12:28:35 -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 cy11sm5711322igc.14.2015.04.27.12.28.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 12:28:35 -0700 (PDT) Message-ID: <553E8DE2.6020202@andyet.net> Date: Mon, 27 Apr 2015 13:28:34 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <20150427181902.3983.35988.idtracker@ietfa.amsl.com> In-Reply-To: <20150427181902.3983.35988.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150427181902.3983.35988.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [xmpp] Fwd: [Uta] Protocol Action: 'Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard (draft-ietf-uta-xmpp-07.txt) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 19:28:38 -0000 FYI. -------- Forwarded Message -------- Subject: [Uta] Protocol Action: 'Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard (draft-ietf-uta-xmpp-07.txt) Date: Mon, 27 Apr 2015 11:19:02 -0700 From: The IESG To: IETF-Announce CC: uta mailing list , uta chair , RFC Editor The IESG has approved the following document: - 'Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)' (draft-ietf-uta-xmpp-07.txt) as Proposed Standard This document is the product of the Using TLS in Applications Working Group. The IESG contact persons are Stephen Farrell and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/ Technical Summary This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120. The document is intended for standards track. Working Group Summary The document extends the UTA TLS BCP to cover XMPP specifics and as such is comparatively less controversial but has still seen enough review to determine consensus. The document has been last-called in both the XMPP and UTA WGs. The review has been mostly done by a small circle of interested individuals. Document Quality Three are I believe implementations that match this spec. Personnel Shepherd: Leif Johansson Irresponsible AD: Stephen Farrell _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta -- Peter Saint-Andre https://andyet.com/ From nobody Thu Apr 30 14:37:25 2015 Return-Path: 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 9EF371A1B49; Thu, 30 Apr 2015 14:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2M1PxtpqhYwI; Thu, 30 Apr 2015 14:37:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA31A1BB5; Thu, 30 Apr 2015 14:35:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430213528.19316.70764.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 14:35:28 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-21.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 21:37:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Author : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-21.txt Pages : 25 Date : 2015-04-30 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-xmpp-6122bis-21 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 30 14:39:00 2015 Return-Path: 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 92BE21A1BA7 for ; Thu, 30 Apr 2015 14:38:59 -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=ham 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 G8QhebBiJsrO for ; Thu, 30 Apr 2015 14:38:58 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (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 093BB1A1B89 for ; Thu, 30 Apr 2015 14:38:58 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so78123077iec.0 for ; Thu, 30 Apr 2015 14:38:57 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1zTnAij8PZhFA3PtggtLjJmIT4mpj3AlCyryvHdvTUw=; b=eQ3MAN7LNDK1s1q3kZwrMr+enmqryqyQQKn5ReLOSnooZFVA4a9XmSHLAYr9D3OaBY ZKGsb5xurFdswV2z1L92MHzUJZcf6e/RDaNJdT1jJzDcFQBE/m/fboFZp8kJC/Wj//Qn /CkbWO7eJwg5OmZ65lZUkh8J24m54tE72119rIYVGnURkLS0doC0yYZnDEOwcvWQ7Td4 XQVeaKNsP1M39G/pLCNigYc+CUIUZnN3fwd+W2zvTbjKKyRAus0S7bkY1yI9yaK5wZ9D tYhen+XMvtTxnQchPSaJyzlklSdHV1nubz670gc/kBurOWlLqBdBN9dpuokyCCfrbZmV gfIQ== X-Gm-Message-State: ALoCoQmoEba8hNHm3oxNArK+twQeY60zUo6HNPt1QBatgSbRvLlOPUzkcQnYPxG0nsF1aJtX0H+P X-Received: by 10.42.152.67 with SMTP id h3mr11559451icw.56.1430429937412; Thu, 30 Apr 2015 14:38:57 -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 k16sm1769757igf.19.2015.04.30.14.38.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 14:38:56 -0700 (PDT) Message-ID: <5542A0EF.9010302@andyet.net> Date: Thu, 30 Apr 2015 15:38:55 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20150430213528.19316.70764.idtracker@ietfa.amsl.com> In-Reply-To: <20150430213528.19316.70764.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-21.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 21:38:59 -0000 On 4/30/15 3:35 PM, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https:https://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-21 Just a few small fixes to the references... Peter -- Peter Saint-Andre https://andyet.com/