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.