Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17

Yaron Sheffer <> Sun, 31 October 2010 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 948833A68DA; Sun, 31 Oct 2010 08:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 31-B+0Q5thTL; Sun, 31 Oct 2010 08:35:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F11043A6991; Sun, 31 Oct 2010 08:35:24 -0700 (PDT)
Received: by 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;; 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;; 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 with SMTP id c2mr14776671wbv.34.1288539443159; Sun, 31 Oct 2010 08:37:23 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id ga16sm4250240wbb.7.2010. (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 08:37:21 -0700 (PDT)
Message-ID: <>
Date: Sun, 31 Oct 2010 17:37:15 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc:,, XMPP <>,
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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
> 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:
> 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:
> 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.

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

>> - 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<>. An example
> of registration can be found in the multi-user chat extension
> <>  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.