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

[Stephen Farrell <[e-mail]>]

Hiya,

Those seem fine. I guess the best is to see out the IETF LC
and then re-spin the I-D,

Thanks,
S.

On 03/04/15 21:05, Peter Saint-Andre - &yet wrote:
> 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
>