Re: [Uta] AD review of draft-ietf-uta-xmpp-05

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

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

On 3/28/15 9:30 AM, Stephen Farrell wrote:
>
> Hiya,
>
> As your non-shiny new helper AD I've reviewed draft-ietf-uta-xmpp-05.
> I have some comments (below), none need hold up IETF LC I think so
> please treat these as you would IETF LC comments.
>
> I'll request IETF LC momentarily.
>
> Thanks,
> S.
>
> - 3.4: I'm not clear what the last paragraph is telling
> me. What should I do about that?

Some motivating and concluding text might be helpful, such as:

OLD
    The Domain Name Associations (DNA) specification [I-D.ietf-xmpp-dna]
    describes a framework for XMPP server authentication methods, which
    include not only PKIX but also DNS-Based Authentication of Named
    Entities (DANE) as defined in [I-D.ietf-dane-srv] and PKIX over
    Secure HTTP (POSH) as defined in [I-D.ietf-xmpp-posh].

NEW
    In some scenarios such as multi-tenanted environments, it can be
    extremely difficult to obtain or deploy PKIX certificates with the
    proper Subject Alternative Names.  To overcome that challenge, the
    Domain Name Associations (DNA) specification [I-D.ietf-xmpp-dna]
    describes a framework for XMPP server authentication methods, which
    include not only PKIX but also DNS-Based Authentication of Named
    Entities (DANE) as defined in [I-D.ietf-dane-srv] and PKIX over
    Secure HTTP (POSH) as defined in [I-D.ietf-xmpp-posh].  These
    methods can provide a basis for server identity verification when
    appropriate PKIX certificates cannot be obtained or deployed.

> - 3.7: practically, is it feasible to provide a client
> with information about server-server uses of TLS? (And
> how many server-server TLS "hops" might there be?)

See my reply to Roni Even's Gen-ART review. It is *not* feasible (at 
least not in a way that would provide information the client could 
trust), and the text was unclear enough to cause confusion. I suggested 
alternative text in my reply to Roni.

> - 3.7: Would it be sensible here to recommend that
> servers log information about the use of TLS so as to be
> able to spot e.g. that what used normally be sent over
> TLS, is now in clear? I'm not sure how feasible it would
> be to do that very well, but maybe we could give
> developers some hints here and see what they come up
> with?

It seems better to require the use of TLS and never allow cleartext 
connections.

> - 5: Would it be worth noting there that this is not e2e
> (obvious I guess) but that that means that some gateways
> (e.g. to SIP) may mean that we even if we really get all
> hops protected, we may not be able to report on that?

This document does not cover gateways, nor does RFC 6120. IMHO text 
about gatewaying belongs the appropriate specifications. For example, 
there is text about it in RFC 7247 and in draft-ietf-stox-im.

> nits:
>
> - 3.5: maybe s/passive eavesdropping/eavesdropping/ and a
> reference to RFC7258 might save someone the trouble about
> arguing that case in XMPP land later.

Good idea.

> - ID nits has some reference version nits, it's fine to
> fix those next time some changes are needed.

Given the scope of changes occasioned by Roni's review, we'll need a 
revised I-D before IESG consideration.

Peter

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