Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 31 October 2010 15:35 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948833A68DA; Sun, 31 Oct 2010 08:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31-B+0Q5thTL; Sun, 31 Oct 2010 08:35:25 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F11043A6991; Sun, 31 Oct 2010 08:35:24 -0700 (PDT)
Received: by mail-ww0-f44.google.com with SMTP id 15so4839471wwe.13 for <multiple recipients>; Sun, 31 Oct 2010 08:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DNyil+hh7JpcEt3N5vMOUE8umoZm3sF4TBoVu23ASxM=; b=POzO5z6/u3DQ51u1wCJKG2FWudSju5bQDC5dDG9Ms6105QfXBk06FV7JnqWe22JyBH 9DVRYKkXG3nJeWfLFoMfUeHaK6su0lZIaBSbAbWlKgnlzF8y7mVVscd0+IKsGgcaW4Fe UVHexCJapyT2Bxo7Rl++Pn7NEBvC5cpfJ7Rao=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=utq7yGhq7sB4gSw1y0GkwIeKApZu0WKgiJVoEEU10tPX6EaEEdyuL4m/aMBI2ZUCEx s1lL0nJIKJfl0cZD8VD+9vG2AA1iSpFv8+XnEJSRWpAK1OxrywUhQY0klEm6SNja8q8l nMYDYZL5gpNfScuJJ0evAfGXH5C0Cb9Qj4JA8=
Received: by 10.227.145.66 with SMTP id c2mr14776671wbv.34.1288539443159; Sun, 31 Oct 2010 08:37:23 -0700 (PDT)
Received: from [192.168.2.119] (bzq-79-182-8-5.red.bezeqint.net [79.182.8.5]) by mx.google.com with ESMTPS id ga16sm4250240wbb.7.2010.10.31.08.37.16 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 08:37:21 -0700 (PDT)
Message-ID: <4CCD8D2B.50900@gmail.com>
Date: Sun, 31 Oct 2010 17:37:15 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCB1334.3030203@stpeter.im>
In-Reply-To: <4CCB1334.3030203@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Oct 2010 15:35:28 -0000
Hi Peter, again, I have removed the points where we are in agreement. Thanks, Yaron On 10/29/2010 08:32 PM, Peter Saint-Andre wrote: > This is Part 2 of my reply, from the start of Section 5 through the end > of Section 9. I should be able to address the remainder (Section 10 > through Section 15) in Part 3. > > On 10/28/10 4:28 AM, Yaron Sheffer wrote: > >> - 5.3.5: the text mentions that client certificates are "sufficiently >> rare", which is a pity because they do make sense for server-to-server >> interaction. So I suggest to promote renegotiation from OPTIONAL to >> RECOMMENDED. > > A bit of background: by client certificates we mean end-user > certificates (XMPP client, not TLS client). PKIX certificates are more > common for XMPP servers, but unfortunately they are still far from > ubiquitous. The XMPP Standards Foundation even ran an intermediate CA > for a few years (under the StartCom root) to help seed the network, > which helped us work out bugs in many codebases but still didn't result > in wide adoption. Many service admins still think that PKI is "too hard" > or "too expensive" (despite the fact that our ICA gave out free > certificates, and StartCom continues to do so). > > The XMPP WG had a discussion about TLS renegotiation, starting here: > > http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html > > At one point we banned TLS renegotiation entirely, then we weighed the > benefits and the costs (including code complexity) and concluded that it > was appropriate to make support strictly optional in XMPP, given how > rarely it would be needed. Simon Josefsson suggested during the WG > discussion that we document our reasons, which we've done in Section > 5.3.5. If you do not find those reasons compelling, the WG needs to > either explain itself more clearly or realize that it is wrong. :) > I accept your reasoning. And servers in most cases can take the risk of information disclosure and still use mutual cert authentication. >> - 5.3.6: extensions may be out of scope. But I think we need to include >> a few words re: the TLS version, at least to prohibit SSL 3.0. > > In fact, discussions within the XMPP WG are what led to this: > > https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/ > > However, it seems there is not yet consensus to prohibit SSL 3.0 in the > TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has not > gone? I was assuming that XMPP has less legacy baggage than HTTP (i.e. browsers) and therefore prohibiting SSLv3 would be reasonable. If it isn't, forget it. > >> - 5.4.3.3: where do we say that both sides must validate the "to" and >> "from" identities in view of the identities presented at the TLS layer >> (if any)? > > Section 13.7.2 ("Certificate Validation"). There is a forward reference > in bullet 4 of Section 5.4.3.3: > > 4. The initiating entity MUST validate the certificate to determine > if the TLS negotiation will succeed; see Section 13.7.2 regarding > certificate validation procedures. > > Perhaps it would be easier to read if we switched bullets 4 and 5 in > that section? Yes, it makes sense to switch #4 and #5. BTW, you meant 5.4.3.1. > > Also, the bullet about validation probably also needs to say that if the > initiating entity presents a certificate then the receiving entity needs > to also perform validation. Do you agree? Yes, this is the basic case, of course it should be mentioned. > >> - 7.7.2.2: the preferred option #1, while reasonable in itself, does not >> allow the client to determine its own policy (whether it wants multiple >> sessions from multiple devices or not). > > If the client wants multiple sessions from multiple devices, it can > generate a unique resourcepart for each device or ask the server to do > so on its behalf. > But if the client prefers the old behavior (newest resource wins), it cannot have it. Anyway, I'm sure you have debated this point to death. >> - 8.3.2: MUST NOT... be presented to the human user - this is impossible >> to enforce, and most likely will not be followed. Moreover, there's a >> reason why we include a language tag. I suggest to tone it down a bit. > > I suppose SHOULD NOT is fine. The error message shown to the user is > supposed to be based on the defined condition, not some random text > placed in the<text/> element (even if language-tagged). Yes, SHOULD NOT would be BETTER... > >> - 8.3.3.11: what are "improper credentials"? It sounds like we are not >> differentiating the conditions of authentication failure vs. >> authorization failure. > > As an example, if a client attempts to join a password-protected > chatroom without providing a password, the chatroom service will return > a<not-authorized/> stanza error. It will return the same error if the > client attempts to join a password-protected chatroom but provides the > wrong password. Is there a need to differentiate between these two cases? > What triggered my comment was the name of this element, "not authorized". Both of your examples are (broadly speaking), "not authenticated". What about the same service, where I am duly authenticated as Yaron, but still am not allowed to use the service, e.g. because only users belonging to the all-saints group are allowed to it. This would be a true authorization failure. > >> - 8.3.3.21: do you explain anywhere what is the difference between >> "prior registration" and "prior subscription"? > > That's really an issue for various XMPP applications. One such > application is IM and presence (3920bis), where we have the concept of > subscriptions. Another application in which we have subscriptions is > publish-subscribe<http://xmpp.org/extensions/xep-0060.html>. An example > of registration can be found in the multi-user chat extension > <http://xmpp.org/extensions/xep-0045.html> or in the older "gateway" > that we used to maintain for connecting to legacy IM services. I don't > see much reason to describe all those differences in 3920bis, but we can > add a sentence or two about it if that would be helpful. > I would appreciate a pointer to benefit the uninitiated.
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre