Hi Peter,
The new text address my comments, I just have a proposal on section 3.5 see
inline
Roni
-----Original Message-----
From: Peter Saint-Andre - &yet [mailto:peter(_at_)andyet(_dot_)net]
Sent: 03 April, 2015 7:34 PM
To: Roni Even; draft-ietf-uta-xmpp(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; XMPP Working
Group; uta(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC review of draft-ietf-uta-xmpp-05
Hi Roni, thanks for the review.
On 4/3/15 3:59 AM, Roni Even wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-uta-xmpp-05
Reviewer: Roni Even
Review Date:2015-4-3
IETF LC End Date: 2015-4-13
IESG Telechat date:
Summary: This draft is not ready for publication as an Standard Track
RFC.
Major issues:
I am wondering why this document is a standard track and not
Informational, reading it I get the impression that it repeats text
from
RFC6120 and does not provide new normative information.
Ah, I see the confusion.
Earlier versions of this document repeated the recommendations from draft-
ietf-uta-tls-bcp and explicitly applied them to XMPP. At some point we
refactored the document so that it wasn't repeating the text (because
that's
usually a bad idea - things can get out of sync etc.), but in the process
we lost
those normative statements.
To fix the problem, I suggest that we change the following paragraph and
move
it to be the first paragraph of Section 3:
OLD
NOTE: Unless explicitly noted otherwise, all of the
recommendations specified in [I-D.ietf-uta-tls-bcp] apply to XMPP.
In the main, this document merely provides supplementary
information; those who implement and deploy XMPP technologies are
expected to follow the recommendations of [I-D.ietf-uta-tls-bcp].
NEW
XMPP implementations and deployments MUST follow the
recommendations provided in [I-D.ietf-uta-tls-bcp] unless
explicitly noted otherwise herein. Instead of repeating those
recommendations here, this document mostly provides supplementary
regarding implementation and deployment of XMPP technologies.
[Roni Even] This is clearer now
Section 3.1 talks about TLS support and say that it SHOULD be tried
but since it is a SHOULD I assume that failure may happen and non TLS
connections may be used ( I am not sure what RFC6120 say about it.
Section 3.1 attempts to say this (but clearly we did not phrase things
very well):
the lack of an indication that a connection endpoint supports TLS SHOULD
NOT
prevent a connecting entity from attempting TLS negotiation. In fact, I
think we
could say MUST NOT (the "SHOULD" comes from local policy).
Therefore I suggest the following rewording:
OLD
The server (i.e., the XMPP receiving entity) to which a client or
peer server (i.e., the XMPP initiating entity) connects might not
offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns
:xmpp-tls'/>. Although in general this stream feature indicates that
the server supports XMPP 1.0 and therefore supports TLS, it is
possible that this stream feature might be stripped out by an
attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]). Therefore,
the initiating entity SHOULD proceed with the stream negotiation even
if the receiving entity does not advertise support for TLS.
Similarly, although a receiving entity SHOULD include the <required/>
child element to indicate that negotiation of TLS is mandatory, an
initiating entity MUST NOT depend on receiving the <required/> flag
in determining whether TLS will be enforced for the stream.
NEW
The server (i.e., the XMPP receiving entity) to which a client or
peer server (i.e., the XMPP initiating entity) connects might not
offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns
:xmpp-tls'/>. Although in general this stream feature indicates that
the server supports XMPP 1.0 and therefore supports TLS, it is
possible that this stream feature might be stripped out by an
attacker (see Section 2.1 of [I-D.ietf-uta-tls-attacks]).
Similarly, the <required/> child element of the <starttls/> stream
feature is used to indicate that negotiation of TLS is mandatory,
but could also be stripped out by an attacker. Therefore, the
initiating entity MUST NOT be deterred from attempting TLS
negotiation even if the receiving entity does not advertise support
for TLS. Instead, the initiating entity SHOULD (based on local
policy) proceed with the stream negotiation and attempt to negotiate
TLS.
[Roni Even] OK
Section 3.4 may look like authentication is a MUST but section 3.5
talks about unauthenticated connections
Well, there are client-to-server connections and server-to-server
connections in
XMPP. The former need to be authenticated and the latter do not (although
we
are working on ways to make authentication easier and more pervasive for
server-to-server connections). I thought we had captured that in the text,
but
perhaps not.
[Roni Even] Maybe start section 3.5 saying that it is only about server to
server connection, currently the end of the section says " this at least
enables encryption of server-to-server connections." But I did not
understand it as saying that this section is only about server to server
connection.
On section 3.7 I assume that providing e2e information is based on the
XMPP architecture that may have only one server to server hop. Are
there other cases?
In Section 3.7 we weren't trying to say that information can be provided
about
the end-to-end encryption status of all the hops along a communications
path
because that's impossible (at least in a way that can be trusted). We
might
adjust the text to avoid any confusion, as
follows:
OLD
o Determine if a client-to-server or server-to-server connection is
encrypted and authenticated.
o Determine the version of TLS used for a client-to-server or
server-to-server connection.
NEW
o Determine if a given incoming or outgoing XML stream is
encrypted and authenticated using TLS.
o Determine the version of TLS used for a given stream.
[Roni Even] OK
Peter
--
Peter Saint-Andre
https://andyet.com/