Re: [Gen-art] Gen-ART LC review of draft-ietf-uta-xmpp-05

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 03 April 2015 21:08 UTC

Return-Path: <peter@andyet.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E541A19F2 for <gen-art@ietfa.amsl.com>; Fri, 3 Apr 2015 14:08:28 -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 z-jCp9jR3D8a for <gen-art@ietfa.amsl.com>; Fri, 3 Apr 2015 14:08:27 -0700 (PDT)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 DEB6A1A1BBE for <gen-art@ietf.org>; Fri, 3 Apr 2015 14:08:26 -0700 (PDT)
Received: by ierf6 with SMTP id f6so98085530ier.2 for <gen-art@ietf.org>; 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=ILpDnyon0uawrUJxdWRJQeUPpq/imZuQ4vwbcjroLJiWOlcBbuwVBeqMwlv3XS4wCv NcJxEhxrgdJ/ZrtFDiXm9M3U5T91QdGSLp76etVRZHaSsEA/lHizjWF7+zTAWJg6Anv0 DmgEyjClQctBXz3W6F08GXxMNtKaN5Apytk3oB6Y5kuYm7vT+XqwFjt/EUJiw4ed489C nICoNONsgpTKLZUzUbV3xBx9LvKCda/Y/JDOO4iHZUNL7CFBAhXR3drTnUttXQTkvNaa At/Aq3t6zYAtz+PQ0hfSSzPjybzxhgoVMEET3e2a3Wdl/HtFm25ZFezSU/Y+zlEK+TR4 rc7w==
X-Gm-Message-State: ALoCoQnAyHdLn2v9jDNuS/9piHB+IQ9pviQzkoRH8w/gkpsIV2G4gxbV2cklJzzCY/DWrhdvniGk
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 <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> <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: <http://mailarchive.ietf.org/arch/msg/gen-art/bwFMI1QcW8I5fO7E02sNQ1T6wW8>
Cc: uta@ietf.org, gen-art@ietf.org, ietf@ietf.org, 'XMPP Working Group' <xmpp@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-uta-xmpp-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2015 21:08:29 -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

<snip/>

>>> 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/