Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)

Peter Saint-Andre - &yet <> Mon, 10 August 2015 23:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 872E21A1BE6 for <>; Mon, 10 Aug 2015 16:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c0ZrCtD1DkU0 for <>; Mon, 10 Aug 2015 16:55:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B57F11A1B4E for <>; Mon, 10 Aug 2015 16:55:22 -0700 (PDT)
Received: by ioeg141 with SMTP id g141so186092800ioe.3 for <>; Mon, 10 Aug 2015 16:55:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ozba4W1LZT/b0JAEwAxb6YzNrt/ot8VNpMhOb9qli28=; b=i+/EbSfm4eEMZfseq8xSaX5JW3kZ+hliUgUtoDBab0QWAv7tXEfNtrAd73oR6BUv19 mbTGQgIe/WET1cWu7EHsueaL0BeGAwe7TswrfnG8b+h5ZoEYtfoJRlBhirwhbrkfYk7z AH6+MeBeMxZIKMA1cyibQlJd4B/LWin/ywr7vmSH104E70vN6Dlb8Ta4t72qfQsGjzli KdQ7Qmf+0NbQSFx6YzNQD4k3LvtnVowy3/yF8xgOmqBPuuSkEIL1qMXypkaTaJPaLWkI g1Oj6+aUTZnlbIm40tDMABzJNoQYLlb7enyzobfKyw1Lz82rlbT6DcdA8Wyo+0EPWHMG 5hPg==
X-Gm-Message-State: ALoCoQlU1V+/J0S1MycksEjY9oR2j5Zjh9r/daiA92iWPKw/hU8ybAfdFHyWwtTEunBRYFtZ10EM
X-Received: by with SMTP id t86mr28944422ioi.103.1439250922071; Mon, 10 Aug 2015 16:55:22 -0700 (PDT)
Received: from aither.local ( []) by with ESMTPSA id cr1sm316932igb.15.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 16:55:20 -0700 (PDT)
To: Stephen Farrell <>, The IESG <>
References: <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Mon, 10 Aug 2015 17:55:18 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2015 23:55:25 -0000

Hi Stephen, thanks for the review, and my apologies regarding the 
delayed reply.

On 8/5/15 9:02 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-xmpp-dna-10: No Objection
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> - section 3: does nobody ever use mutually authenticated
> TLS for this with XMPP? (Just wondering.)

As Kim noted, it happens, but it's not yet widespread.

> - 3.2: I didn't know that XMPP clients send a user ID in
> cleartext before turning on TLS.

They can. Section 4.7.1 of RFC 6120 states:

For initial stream headers in client-to-server communication, the
'from' attribute is the XMPP identity of the principal controlling
the client, i.e., a JID of the form <localpart@domainpart>. The
client might not know the XMPP identity, e.g., because the XMPP
identity is assigned at a level other than the XMPP application layer
(as in the Generic Security Service Application Program Interface
[GSS-API]) or is derived by the server from information provided by
the client (as in some deployments of end-user certificates with the
SASL EXTERNAL mechanism). Furthermore, if the client considers the
XMPP identity to be private information then it is advised not to
include a 'from' attribute before the confidentiality and integrity
of the stream are protected via TLS or an equivalent security layer.
However, if the client knows the XMPP identity then it SHOULD include
the 'from' attribute after the confidentiality and integrity of the
stream are protected via TLS or an equivalent security layer.

> Pity that.  Is it ok
> for a client to fake that and then later authenticate as
> a different entity such as "usertwo@a.example"?

The 'from' is not required on initial stream headers, and it is 
perfectly acceptable to not include it (which is what most clients do).

> - 3.2, step 5: "proving" isn't quite right but is good
> enough here.

OK. We are using "proof" here in the sense later described in Section 5:

    The foregoing protocol flows assumed that domain name associations
    were proved using the PKI prooftype specified in [RFC6120]: that is,
    the server's proof consists of a PKIX certificate that is checked
    according to the XMPP profile [RFC6120] of the matching rules from
    [RFC6125] (and the overall validation rules from [RFC5280]), the
    client's verification material is obtained out of band in the form of
    a trusted root, and secure DNS is not necessary.

Perhaps a forward pointer would be helpful?

> - 4.1: Please separate the seperable pictures by at
> least some whitespace but ideally with captions.  Right
> now it looks initially as if it's just one big figure.
> At present, I find that figure makes things less clear
> rather than more.

OK, we'll try to break it into smaller chunks.

> - 4.2, bullets: the 2nd last one here is really similar
> to the 1st two (as I read 'em). Maybe consider merging.

I don't quite follow.

> And the use of "is trusted by" in the 1st two is a bit
> inaccurate, but could be lived with;-)

Maybe "is acceptable to" would be better? I agree that "trust" is a 
slippery notion.

> - 4.4.1: should the refs for dialback (and the "first
> specified..." comment) be earlier?

There is a reference in the first paragraph of Section 4, but do you 
mean that it needs to be mentioned even sooner?

> - 5.1: Is there going to be another "XMPP with DANE
> prooftype" document? I'm not sure that 5.1 alone is
> enough, and there is one for POSH, so I wondered.

At IETF 89, Matt and I chatted with Jon Peterson, who was concerned 
about the possible need to write DANE-SRV profile documents for every 
SRV-using application protocol. To address his concern, we established 
reasonable defaults in draft-ietf-dane-srv, thus enabling application 
protocol specifications to re-use what's in draft-ietf-dane-srv or use 
it with only slight modifications or additions. The last two bullet 
points in draft-ietf-xmpp-dna specify some adjustments for XMPP, but 
everything *should* be covered by draft-ietf-dane-srv. Or at least that 
was the intent.

> - 5.2: does this repeat text from the POSH I-D?  If so,
> is that a good idea?
> - 8.1: Huh? Why aren't these in the POSH I-d?

Although we went back and forth on the matter for a long time, we 
eventually decided to place the XMPP DNA prooftype information (such as 
the .well-known registrations and the prooftype definitions) for both 
the DANE prooftype and the POSH prooftype in the XMPP DNA spec. The 
reasoning is that theoretically the POSH I-D is not XMPP-specific and 
could be re-used by other application protocols (as can the DANE-SRV I-D).

> - 8.1/8.2: Is it a good/bad idea to have structure in
> the .well-known URIs and where that structure is not a
> pathname? Personally, I think it's not a great idea but
> that's just a personal preference.

As you know, see the thread with Barry.

> I also don't think
> "_tcp.json" is good to include in the URI.

Why not?


Peter Saint-Andre