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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 08:02:25 -0700

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 3: does nobody ever use mutually authenticated
TLS for this with XMPP? (Just wondering.)

- 3.2: I didn't know that XMPP clients send a user ID in
cleartext before turning on TLS. Pity that.  Is it ok
for a client to fake that and then later authenticate as
a different entity such as "[email-masked]"?

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

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

- 4.2, bullets: the 2nd last one here is really similar
to the 1st two (as I read 'em). Maybe consider merging.
And the use of "is trusted by" in the 1st two is a bit
inaccurate, but could be lived with;-)

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

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

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

- 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. I also don't think
"_tcp.json" is good to include in the URI.

---

From: Kim Alvefur <[email-masked]>
Date: Sat, 08 Aug 2015 18:25:09 +0200

Hi,

Just want reply to these:

> TLS for this with XMPP? (Just wondering.)

No, mutual authentication using TLS for client-to-server connections is
used, I believe, in some environments.

> a different entity such as "[email-masked]"?

I don't think many clients really do that, for privacy concern.  Our
server implementation doesn't care about the stream 'from' on client
connections, regardless of security and authentication.

-- 
Kim "Zash" Alvefur

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 10 Aug 2015 17:55:18 -0600

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

> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

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

> 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

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

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?

> At present, I find that figure makes things less clear

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

> to the 1st two (as I read 'em). Maybe consider merging.

I don't quite follow.

> inaccurate, but could be lived with;-)

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

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

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

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

> that's just a personal preference.

As you know, see the thread with Barry.

> I also don't think

Why not?

Peter

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