Re: [Uta] Barry Leiba's Yes on draft-ietf-uta-xmpp-06: (with COMMENT)

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 20 April 2015 21:58 UTC

Return-Path: <peter@andyet.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3CA1B32AB for <uta@ietfa.amsl.com>; Mon, 20 Apr 2015 14:58:07 -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 3sWxLOQRupXz for <uta@ietfa.amsl.com>; Mon, 20 Apr 2015 14:58:06 -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 9F3401B32AD for <uta@ietf.org>; Mon, 20 Apr 2015 14:58:02 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so340611ied.1 for <uta@ietf.org>; Mon, 20 Apr 2015 14:58:02 -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=C+I1hXNopRC23wXNJxrO76K9tF/tUUQHo/i10QXf+Wo=; b=CZqawY5c9H3UT+30aoR8qV/JkyysKcecCicfF6b90zLrrdfMf4JimObu21PPr5uiQo S0gvQOep5z/aKgUNfLnzo8GROa4k2S6nI5DXkpZnFIaE2YOxRl0R0F/UROy3DNdEb58w 16p+oJqMxhskSwStHk0AQ4LRnxkLEBFpATdqp3SoZHJfWWQR+l7kh+xqVA4eBNGiSRLe x2VjMWrnQ6+erqPUeyHcmuiCLYJE3mDi2n6T+7S3RiSMnD/lyTrnIdBEZnCuvEcvAsWS JpbJBhRzi1SPkGRCVsOVWP6bEIuFsnK8MB9FOBTmi1g6mwpEQZTj7vTvYjmgP0aUgJMJ geiQ==
X-Gm-Message-State: ALoCoQl7lAi01hdX47Nrr9MdSDWLh6+2VKCc3ef4XVyy40dHVc/xGPFH4HX+KjkdvtYdpx9KeFyg
X-Received: by 10.42.37.5 with SMTP id w5mr21080739icd.39.1429567082035; Mon, 20 Apr 2015 14:58:02 -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 z195sm12122324iod.33.2015.04.20.14.58.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 14:58:01 -0700 (PDT)
Message-ID: <55357667.3070309@andyet.net>
Date: Mon, 20 Apr 2015 15:57:59 -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.6.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
References: <20150420214313.17988.96083.idtracker@ietfa.amsl.com>
In-Reply-To: <20150420214313.17988.96083.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/CxtJiQAnb9MpoPbGPyjbRFBkNYk>
Cc: uta-chairs@ietf.org, draft-ietf-uta-xmpp.ad@ietf.org, uta@ietf.org, draft-ietf-uta-xmpp@ietf.org, draft-ietf-uta-xmpp.shepherd@ietf.org, leifj@sunet.se
Subject: Re: [Uta] Barry Leiba's Yes on draft-ietf-uta-xmpp-06: (with COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2015 21:58:07 -0000

Hi Barry, thanks for the review. Comments inline.

On 4/20/15 3:43 PM, Barry Leiba wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-uta-xmpp-06: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> -- Section 3.4 --
>
>     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.
>
> How does "prefer" "whenever possible" match up with "MUST" and "MUST"?
>
> Ah, I see; in the next paragraph, we have server-to-server
> authentication, which isn't a MUST.  Got it.  So, purely optional if you
> agree with me, but I'd find it less confusing like this:
>
> NEW
>     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.
>     * Servers MUST authenticate clients.
>     * Servers SHOULD authenticate other servers.
>
>     This document does not mandate that servers need to authenticate
>     peer servers, although such authentication is strongly preferred.
>     Unfortunately, [...etc...]
> END

Yes, that's more readable for sure!

> -- Section 3.6 --
>
> I understand that, while most users won't understand it, there's value in
> trying to communicate to an end user that she is using a secure
> connection.
>
> I am very skeptical that there's the slightest bit of value in giving end
> users information about the version of TLS used, the mechanism for
> verification, the details of the certs (if any), or the details of the
> cipher suite.  I'm certainly skeptical that making that available to end
> users should rise to the level of "strongly encouraged".  I'm not going
> to block anything with regard to this, but I see this as something you
> might strongly encourage be available to an administrator, but not to an
> end user (other than, perhaps, by enabling detailed logging through an
> advanced setting, then inspecting the logs).

At one point in the history of this document, we had separate bullet 
lists for administrators and end users. There was so much overlap that 
it was confusing. However, we might consider bringing that back.

Peter

-- 
Peter Saint-Andre
https://andyet.com/