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

[Peter Saint-Andre - &yet <[e-mail]>]

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

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 "[e-mail]"?

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

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