Hi Elwyn, Thanks for your reply. Unfortunately I got impatient and submitted a revised I-D earlier today (-20), but I can always submit another one if needed. Version numbers are cheap. :)
Comments inline.
On 12/10/10 11:18 AM, Elwyn Davies wrote:
>
> Hi, Peter.
>
> Sorry I was not responsive on checking your quick reponses here. Have
> been rather tied up with a draft I am authoring (and have the editor's
> pencil for at the moment).
>
> A few points from reviewing the diff you pointed to - it is mostly an
> excellent update:
> 4.7.1.. use MAY about 'from' rather than SHOULD? Does the note apply
> only to connected clients only? There is a MUST for servers. Section
> 4.8.3's comments on jabber-client vs jabber-server may be relevant.
Do you mean this note?
Security Warning: Notwithstanding the recommendations in the
remainder of this section, the initiating entity SHOULD NOT
include a 'from' address on the initial stream header it sends
before the confidentiality and integrity of the stream are
protected via TLS or an equivalent security layer (such as the
SASL GSSAPI mechanism), since doing so would expose the initiating
entity's identity to eavesdroppers.
I think that applies to both servers and clients, if they care to
protect their identity from casual eavesdroppers on the very first
stream header (before TLS or similar protection)
> 4.9.1.1: Should the shall in the last sentence be SHALL?
I have tried to use no lowercase instances of the capitalized keywords,
but missed that one. Fixed.
> 5.2 SHOULD -> RECOMMENDED if available but not mandatory-to-negotiate.
Don't SHOULD and RECOMMENDED mean the same thing?
RFC 2119 says:
###
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
###
> 13.9.1: Base64 -> Base 64 in the section title.
I tried to make our terminology consistent with RFC 4648, but missed the
title (and one instance in Section 6.5.5). Fixed.
> 14.x: email addresses x...@ietf.org -> i...@ietf.org
Fixed.
> In line comments about changes...
>
> On Tue, 2010-11-30 at 14:59 -0700, Peter Saint-Andre wrote:
>> Hi Elwyn, thank you for reviewing this long document on such short notice.
>> I'm cc'ing x...@ietf.org to keep the XMPP WG in the loop, as well as
>> i...@ietf.org.
>>
>> On 11/29/10 6:21 PM, "Elwyn Davies" <elw...@dial.pipex.com> 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 wait for direction from your document shepherd
>>> or AD before posting a new version of the draft.
>>>
>>> [Apologies to the author: This document slipped through the gen-art
>>> last call review net and so I only got to volunteer on this one 24 hours
>>> ago.]
>>>
>>> Document: draft-ietf-xmpp-3920bis-19
>>> Reviewer: Elwyn Davies
>>> Review Date: 29 November 2010
>>> IETF LC End Date:
>>> IESG Telechat date: 2 December 2010
>>>
>>> Summary:
>>> This is a very well written document that is mostly easy to read and
>>> follow. However I believe it is not (quite) ready for the IESG for the
>>> following reasons:
>>>
>>> It has (IMO) one major issue as an EXTENSIBLE system - the three level-1
>>> stanzas are hard coded and it is not immediately possible to add new
>>> types of level-1 stanza should this be thought useful in future.
>>
>> That has been the design of XMPP since 1999 and it has not visibly slowed
>> the development of a wide range of XMPP extensions. From this I conclude
>> that the existing stanza types appear to cover all of the communication
>> primitives that have been needed in the XMPP community. Furthermore, the
>> extensibility model was documented in RFC 3920 and this I-D merely provides
>> updated documentation for the core XMPP protocols by obsoleting RFC 3920.
>> It's a bit late to be changing it now. Besides, I imagine that if we want an
>> even more flexible extensibility model, we'll develop XMPP 2.0. :)
>
> I think this was covered OK in the subsequent email...
> You suggested
>
>> How about if we add the following paragraph right after the definition
>> of
>> "XML Stanza" in Section 4.1?
>>
>> There are three kinds of stanzas: message, presence, and IQ (short
>> for "Info/Query"). These stanza types provide three different
>> communication primitives: a "push" mechanism for generalized
>> messaging, a specialized "publish-subscribe" mechanism for
>> broadcasting information about network availability, and a
>> "request-
>> response" mechanism for more structured exchanges of data (similar
>> to
>> [HTTP]). Further explanation is provided under Section 8.2.1,
>> Section 8.2.2, and Section 8.2.3, respectively.
>>
>
> I think this covers the situation OK.
Good.
>>> There are several more minor issues with these two being important:
>>> There are also a largish number of SHOULD requirements where the
>>> alternative is not discussed or specified.
>>
>> This is true. When the alternatives are not security-critical, we have in
>> general left them up to the best judgment of software developers and service
>> operators.
>>
>> I'll also admit that it's a lot of work to document the alternatives to each
>> SHOULD-level requirement, and that the XMPP WG and the spec writer might
>> lack energy to do that in all cases. A quick grep yields 137 instances of
>> SHOULD or RECOMMENDED, and I'd expect that well over 100 of those do not
>> document the alternatives.
>>
>> That said, if you have concerns about specific instances of those
>> conformance terms, please let me know. In the meantime, I will endeavor to
>> look at them all, although I won't have time to do so until after the IESG
>> telechat this Thursday at the earliest.
>
> A few notes on the SHOULDS (-19 section numbers) - omitted ones seem
> fine:
>
> s3.2.3: This SHOULD is a policy/implementation issue. It doesn't affect
> protocol implementation SHOULD -> should or ought to.
Sure. I don't think folks are too strict about conformance terms in
relation to implementation decisions, but I suppose you're right in this
case. Changed to "is encouraged to"...
> s3.3: I'd go for MUST in both cases.. don't you get beaten up about
> congestion otherwise?
I don't think this rises to the level of an absolute commandment. It's
network-friendly, but nothing breaks absolutely if it's not followed.
> s4.6.4, last para: The first strikes me as a MUST (although there is the
> obvious get out if the receiver's default is what the initiator
> specifies). There seems to be a not-very-subtle bug in the generated
> text bit.. If the receiver doesn't support the initiator's default
> language then putting the initiator's specified language on to a
> generated message that isn't in that language ('cos the receiver doesn't
> do it) sounds rather stupid.
It's not the intended recipient that we're talking about here, it's the
routing server. If I tell my server that my preferred language is
'de-CH' but it can't send me error messages (etc.) in 'de-CH', it can
still stamp my outbound stanzas with 'de-CH' on my behalf.
> s4.6.5, item 3: .. and close the stream. I guess the receiver might
> want to log why it didn't succeed.
A stream error is always followed by a stream close (Section 4.9.1.1),
so I don't see a reason to add those four words here.
However, I've added pointers to the specific sections for each error
condition whenever they are mentioned, and fixed up a few other places
where we followed "send a stream error" with "and close the stream".
> s4.6.5, item 4: Do typical legacy servers barf or ignore if they get a
> version attribute? If barf, then maybe it should be MUST.
Those would be rather old legacy servers now (pre-2004), and as far as I
know they ignore the 'version' attribute (I think we would have known
about it by now if they barfed).
> s5.2: SHOULD -> HIGHLY RECOMMENDED
there is no HIGHLY RECOMMENDED in RFC 2119. :) I think "SHOULD" is fine.
> s5.4.3.3, item 5: discussed below.
>
> s8.2.1: Isn't this a 'will contain a 'to' except if it is going to the
> connexted client's account on the server'?
Sure. Changed to:
The <message/> stanza is a "push" mechanism whereby one entity pushes
information to another entity, similar to the communications that
occur in a system such as email. All message stanzas will possess a
'to' attribute that specifies the intended recipient of the message
(see Section 8.1.1 and Section 10.3), unless the message is being
sent to the bare JID of a connected client's account. Upon receiving
a message stanza with a 'to' address, a server SHOULD attempt to
route or deliver it to the intended recipient (see Section 10 for
general routing and delivery rules related to XML stanzas).
>>> There seems to be a lack of clarity or definiteness about the effects of
>>> support of SASL being mandatory. There are a number of places in the
>>> document where the text is written as if SASL were not mandatory, and
>>> others where the reverse is true but the surrounding text doesn't seem
>>> to think it is mandatory.. All these places need to be looked at
>>> critically to ensure that the wording is appropriate for SASL being
>>> mandatory and that the whole is consistent.
>>
>> From the perspective of software development, SASL authentication is
>> mandatory-to-implement for all clients and servers.
>>
>> From the perspective of service deployment, SASL authentication is
>> mandatory-to-negotiate without qualification for all client-to-server
>> streams. By contrast, for server-to-server streams, in practice SASL
>> authentication is used only in the case of TLS + SASL EXTERNAL with PKIX
>> certificates (in theory it could be used in the case of pre-shared secrets
>> between servers, but I am not aware of any deployment of such a solution).
>> However, many deployed XMPP services still do not have PKIX certificates and
>> therefore fall back to weak identity verification using the Server Dialback
>> protocol that was documented in RFC 3920 but has since been pulled out into
>> a separate spec. While we would love to say that TLS + SASL EXTERNAL is
>> mandatory-to-negotiate without qualification for all server-to-server
>> streams, such a mandate would be so far out of alignment with deployed
>> reality that people would just ignore it anyway.
>>
>> However, here again I'll take another look at the text to make sure that
>> these matters are clear. In part, some of the confusion might derive from
>> the fact that in some places we use the term "mandatory" alone, rather than
>> "mandatory-to-implement" or "mandatory-to-negotiate". I have fixed all such
>> instances in my working copy.
>
> I think the changes in if candaidate -20 cover the situation well.
>>
>>> Apart form these there are a number of other minor issues and various
>>> nits/editorial issues.
>>>
>>> Caveat: As usual I haven't tried to verify the XML in Appendix A, and my
>>> scan of the examples in s9 was very cursory.
>>>
>>> Major issues:
>>> s4.1, Definition of XML Stanza: Given that xmpp is supposed to be
>>> extensible, is there a really good reason why the first-level
>>> stanza=defining elements (message, presence, iq) are hard-coded into the
>>> specification rather than being possibly extensible? There is already a
>>> stream features mechanism where additional first-level items could be
>>> signlaed.
>>
>> And there's been absolutely no demand for new first-level elements. I'm not
>> saying there never will be such demand, but to date the XMPP community has
>> been able to do everything it's wanted to do using the existing stanza
>> types.
>
> OK.. we negotiated on this already.
>>
>>> Minor issues:
>>> s2.5, first bullet describing server respnsibilities: The term 'local
>>> clients' is slightly confusing. My immediate understanding of 'local'
>>> would be something attached to the server from the local network or
>>> machine. In this case it is presumably intended to imply clients that
>>> have a session connected to this server rather than via some other
>>> server but may of course be very remote as regards physical and network
>>> location. Maybe 'attached clients' or 'associated clients' (this term
>>> is used elsewhere in the document) might be clearer, or maybe this just
>>> needs a terminology definition for how 'local' is used - there is the
>>> use of 'local entities' previously in s2.5 but this didn't jar so much.
>>
>> Elsewhere in this document we use the term "connected client", so I propose
>> using that term here as well.
>
> Fine.
>
>>
>>> s2.5, last para: Does the use of 'local services' imply anything about
>>> the disposition of the code implementing the service? This use of
>>> 'local' may or may not conflict with the implications of 'local
>>> mentioned in the last comment. Terminology needs to be made a little
>>> more rigorous.
>>
>> Elsewhere in this document we use the term "add-on service", so I propose
>> using that term here as well.
>
> OK.
>
>>
>>> s4.2.2: Towards the end of this section, there are two statements
>>> stating 'the initiating entity is cleared to send XML stanzas'. Should
>>> this be qualified with 'unless a stream restart is required as a result
>>> of the feature negotiation' (at least at the first appearance)? This
>>> probably depends on whether voluntary-to-negotiate features can require
>>> stream restarts if agreed but not otherwise.
>>
>> The fact that the initiating entity is cleared to send stanzas is orthogonal
>> to whether a stream restart might be required after negotiation of a
>> voluntary-to-negotiate feature -- even if a voluntary-to-negotiate feature
>> required a stream restart (and so far none of them do), the initiating
>> entity would still be cleared to send stanzas.
>>
>> Also note that stream restarts are something of a legacy "feature" (bug?),
>> because back in ~2003 we thought a stream restart would be necessary to
>> flush the security context of a stream after negotiation of TLS or
>> negotiation of a SASL mechanism that enforced a security layer. However, in
>> fact that really wasn't necessary and if we did it over again we might
>> remove stream restarts entirely. But there was no appetite in the WG for
>> making such a large change in 3920bis, so stream restarts remain as a kind
>> of legacy feature (bug?).
>
> OK.. happy to accept as is.
>>
>>> s4.2.3 and s4.4: In s4.2.3, if a stream has to be restarted, the parties
>>> are supposed to consider the the stream 'replaced'. This presumably
>>> means that the old stream is closed. It is not absolutely clear whether
>>> this requires that a <stream/> is exchanged or definitely not exchanged
>>> in this case. [OK: This is cleared up for the specific TLS case at item
>>> 3 in s5.4.3.3 and for SASL in s6.4.6 - a general note at s4.2.3 would be
>>> appropriate since these are not necessarily the only restart cases.]
>>
>> Section 4.2.3 states in part:
>>
>> The initiating entity then MUST send a new initial stream header,
>> which SHOULD be preceded by an XML declaration as described under
>> Section 11.5.
>>
>> That seems clear to me.
>>
>> However, this would be even clearer:
>>
>> On successful negotiation of a feature that necessitates a stream
>> restart, both parties MUST consider the previous stream to be
>> replaced but MUST NOT send a closing </stream> tag and MUST NOT
>> terminate the underlying TCP connection; instead, the parties MUST
>> reuse the existing connection, which might be in a new state (e.g.,
>> encrypted as a result of TLS negotiation). The initiating entity
>> then MUST send a new initial stream header, which SHOULD be preceded
>> by an XML declaration as described under Section 11.5.
>>
> All cleared up in -20
>
>>> s4.2.6, paras 2 and 3: The first parts of these paragraphs are written
>>> as if SASL autrhentication was mandatory (which it is) and is the only
>>> possibility (which it might not be). Para 2 (the client-to-server case)
>>> does not appear to allow for any other options. Para 3, OTOH, goes on
>>> to deal with Server Dialback but the first part still reads as if SASL
>>> was the only option. Both paras need to be rewritten to cater for other
>>> options (and the version 0.9 case?).
>>
>> See above about wiggle room for weak identity verification using Server
>> Dialback.
>>
>> Before SASL, we did also have another method for client authentication, but
>> that is completely deprecated, unlike Server Dialback (which unfortunately
>> clings to life despite our best efforts to drive a stake through its heart).
>
> I understand what is going on here. I think the (minor) problem here is
> the word 'typically'. It would not hurt to remind people again that
> SASL is (currently) the only client-to-server auth mechanism and so the
> determination is all in terms of SASL. If somebody came up with another
> mechanism that could be an alternative (but one or other MUST be used)
> then the words would be different. How about (starting the second para):
>
> For client-to server communication use of SASL is mandatory-to-negotiate
> and no alternative mechanisms are currently specified. Hence the
> clients's bare...
Makes sense. I now have:
After the parties to an XML stream have completed the appropriate
aspects of stream negotiation, the receiving entity for a stream MUST
determine the initiating entity's JID.
For client-to-server communication, both SASL negotiation (Section 6)
and resource binding (Section 7) MUST be completed before the server
can determine the client's address. The client's bare JID....
>>> s4.6.1, para 6:
>>> 'For initial stream headers in server-to-server communication, a
>>> server MUST include the 'from' attribute and MUST set the value to
>>> the domainpart of the 'from' attribute of the stanza that caused the
>>> stream to be established...': Is it absolutely always the case that
>>> a server-to-server connection would be established because some stanza
>>> came in (presumably from an attached client)? Could this be indirectly
>>> through some local service requiring a connection for any other reason?
>>> It is clear why the server needs to specify 'from' but the constraint
>>> on the origin seems overly restrictive.
>>
>> There's no reason to establish a server-to-server connection unless a server
>> needs to send a stanza to a peer server. The triggering stanza might have
>> been generated by a connected client, an add-on service, or even the server
>> itself. Unlike end users, servers don't connect to each other just because
>> they're lonely. :)
>
> Fair enough.
>
>>
>>> s5.3.5: 'Because it is relatively inexpensive to establish streams in XMPP,
>>> for the first two cases it is preferable to use an XMPP stream reset
>>> (as described under Section 4.8.3.16) instead of performing TLS
>>> renegotiation.':
>>> Is this always true? Probably so for simple instant messaging but if
>>> the client is using some other services provided by the server, this may
>>> an unwarranted generalization. I am not sufficiently expert in either
>>> XMPP or TLS renegotiation to know what the trade-offs would be.
>>
>> The XMPP WG had a fair amount of discussion about the tradeoffs and came to
>> the conclusions summarized in that section. The cost here is not really
>> related to the application that is operated after streams are negotiated
>> (and don't assume that IM is a simple or inexpensive application!), but to
>> the process of establishing streams in the first place no matter what
>> application is operated over the stream.
>
>>> s5.3.5: 'However, the third case is sufficiently rare that XMPP entities
>>> SHOULD NOT blindly attempt TLS renegotiation.' (the third case is
>>> separating client authentication from server authentication):
>>> I don't understand what is being said here. Is this an opinion that the
>>> risk of client credential leakage is sufficiently low that the expense of
>>> two stage negotiation is not really worth it? Or is this something that
>>> should be controlled by a configurable client policy? Or is this an
>>> implementation choice? Some clarification would help.
>>
>> The WG came very close to saying that XMPP entities MUST NOT use TLS
>> renegotiation because in general the costs (e.g., code complexity) outweigh
>> the benefits. However, as described there is one case when it might be
>> useful. Yet that case is quite rare, because in this case essentially the
>> client doesn't trust the server and won't send its TLS credentials to the
>> server until after the server has authenticated to the client. So far we
>> don't know of any client implementations or deployments that are
>> sufficiently paranoid to behave that way and in any case end-user
>> certificates are extremely rare at this point in the evolution of XMPP
>> technologies. In the case of server-to-server connections, the server that
>> acts as a TLS client uses a PKIX certificate as its credential and such
>> certificates are public anyway, so there's no possibility of leaking private
>> information. End-user certificates also tend to be public in that way
>> (although the user might worry about leaking their bare JID before the
>> stream is protected).
>>
>> To clarify these matters, I suggest the following modified text:
>>
>> The third case has improved security characteristics when the TLS
>> client (which might be an XMPP server) presents credentials to the
>> TLS server. If communicating such credentials to an unauthenticated
>> TLS server might leak private information, it can be appropriate to
>> complete TLS negotiation for the purpose of authenticating the TLS
>> server to the TLS client and then attempt TLS renegotiation for the
>> purpose of authenticating the TLS client to the TLS server. However,
>> this case is extremely rare because the credentials presented by an
>> XMPP server or XMPP client acting as a TLS client are almost always
>> public (i.e., a PKIX certificate) and therefore providing those
>> credentials before authenticating the XMPP server acting as a TLS
>> server would not in general leak private information.
>>
>> As a result, implementers are encouraged to carefully weigh the costs
>> and benefits of TLS renegotiation before supporting it in their
>> software, and XMPP entities that act as TLS clients are discouraged
>> from blindly attempting TLS renegotiation unless the certificate (or
>> other credential information) sent during TLS negotiation is known to
>> be private.
>>
> I am happy with the text in -20.
>
>>> s5.4.3.1, rule 3: Why should the receiving entity not request a certificate?
>>
>> Perhaps it has no expectation that initiating entity will be able to provide
>> a certificate. I don't think the WG had consensus to say MUST here, but I'll
>> bring this up on the WG list.
>>
>>> Why would the initiating entity not send its certificate if it had one? (Is
>>> this related to the renegotiation issue from the last comment?)
>>
>> Yes, it is related -- the initiating entity might not want to send its
>> (private) credential information until after the receiving entity has itself
>> authenticated to the initiating entity.
>
> I think it might be worth pointing out the potential privacy issue here.
I now have:
3. So that mutual certificate authentication will be possible, the
receiving entity SHOULD send a certificate request to the
initiating entity and the initiating entity SHOULD send a
certificate to the receiving entity (but for privacy reasons
might opt not to send a certificate until after the receiving
entity has authenticated to the initiating entity).
>>> s5.4.3.1, rule 4: How should the receiving entity make the choice given the
>>> 'to' attribute (presumably some field in the certificate)?
>>
>> Here the 'to' attribute essentially functions like a Server Name Indication
>> in TLS. If the server has multiple certificates based on domain name (e.g.,
>> in a virtual hosting environment), it can figure out which certificate to
>> present based on the domain name contained in 'to' address. I suggest the
>> following text clarification:
>>
>> 4. The receiving entity SHOULD choose which certificate to present
>> based on the domainpart contained in the 'to' attribute of the
>> initial stream header (in essence, this domainpart is
>> functionally equivalent to the Server Name Indication defined for
>> TLS in [TLS-EXT]).
> OK.. but ...
>>
>>> What happens if
>>> it decides not to follow this should?
>>
>> The TLS negotiation might fail because the initiating entity would think
>> it's connecting to example.com but the receiving entity would present a
>> certificate for example.org (or whatever).
>
> .. so isn't this a lower case 'should': the validation will fail if it
> makes a wrong choice but it isn't a protocol requirement
Leading to unnecessary reconnection attempts and round trips. Seems to
me that SHOULD is still appropriate here.
>> However, note that this doesn't apply if the XMPP server is servicing only
>> one domain, which is by far the most common deployment scenario.
> Indeed.
>
>>
>>> s5.4.3.2, para 2: The comment about not sending </stream> relates to the
>>> comment on s4.3.2 above. However, the reasoning for not sending </stream>
>>> when the TCP connection is closed due to TLS failure differs from reasoning
>>> given elsewhere (e.g., s5.3.5, para 8 - here the error is said to be at the
>>> TLS layer and not the XMPP layer so that it is not appropriate to send
>>> </stream>).
>>> A consistemt story is needed here.
>>
>> The text in Section 5.3.5 is more correct, thus I propose this in 5.4.3.2:
>>
>> The receiving entity MUST NOT send a closing </stream> tag before
>> terminating the TCP connection (since the failure has occurred at the
>> TLS layer, not the XMPP layer; see Section 13.3).
>>
>> (The text about the stream being replaced applies to TLS success but not TLS
>> failure.)
>
> All clear now.
>
>>
>>> s5.4.3.3, item 5: Given that SASL support is mandatory, why is offering the
>>> SASL
>>> feature not a MUST? Is this to do with possible future alternatives?
>>
>> In the server-to-server case, if the peer server did not present a
>> certificate then SASL won't be possible. See above.
>>
> You have added excellent text in s6.4.1 to explain when the SHOULD
> applies.. a pointer would help.
Done.
>>> s6.3.8, para 1: I suspect the two SHOULDs in this para ought to be MUSTs.
>>> What
>>> other options does initiating entity have if it does/does not want to act on
>>> behalf of another entity and SASL is being used?
>>
>> None. So I think MUST and MUST NOT are appropriate (with the understanding
>> that they are hypothetical imperatives anyway, not categorical imperatives).
>>
> OK
>
>>> However maybe all this
>>> should be
>>> qualified by 'If SASL is being used...'
>>
>> I think not.
>>
> OK
>
>>> s6.4.1, para 5: 'If the receiving entity supports SASL, the stream features
>>> SHOULD include an advertisement for support of SASL negotiation,...':
>>> s6.2 says that XMPP entities MUST support SASL.
>>
>> Right. The clause "If the receiving entity supports SASL" is a legacy of RFC
>> 3920, when SASL was new. The clause can be safely removed now (all other
>> instances have been removed, but we missed this one).
>>
> Fine.
>
>>> I think that this sentence
>>> probably needs to be turned round making it something like 'Unless support
>>> for
>>> SASL
>>> negotiation is only allowed once STARTLS negotiation has been completed, the
>>> stream features MUST include an advertisement for the support of SASL.'
>>> Aside
>>> from
>>> the STARTLS case (or equivalent cases with future secure stream mechanisms),
>>> what
>>> happens if the SASL advertisement is not made?
>>
>> I think that changing the sentence as you propose is not correct, because it
>> closes off all other reasons for not advertising support for SASL (and,
>> because SASL is mandatory-to-negotiate if advertised, thus forcing an
>> attempt at SASL negotiation).
>>
>> For completeness, I think it would be best to adjust the text in this
>> section as follows:
>>
>> ###
>>
>> 6.4.1. Exchange of Stream Headers and Stream Features
>>
>> If SASL negotiation follows successful STARTTLS negotiation
>> (Section 5), then the SASL negotiation occurs over the encrypted
>> stream that has already been negotiated. If not, the initiating
>> entity resolves the hostname of the receiving entity as specified
>> under Section 3, opens a TCP connection to the advertised port at the
>> resolved IP address, and sends an initial stream header to the
>> receiving entity. In either case, the receiving entity will receive
>> an initial stream from the initiating entity.
>>
>> I: <stream:stream
>> from='jul...@im.example.com'
>> to='im.example.com'
>> version='1.0'
>> xml:lang='en'
>> xmlns='jabber:client'
>> xmlns:stream='http://etherx.jabber.org/streams'>
>>
>> When the receiving entity processes an initial stream header from the
>> initiating entity, it MUST send a response stream header to the
>> initiating entity (for which it MUST generate a unique stream ID; if
>> TLS negotiation has already succeeded then this stream ID MUST be
>> different from the stream ID sent before TLS negotiation completed).
>>
>> R: <stream:stream
>> from='im.example.com'
>> id='vgKi/bkYME8OAj4rlXMkpucAqe4='
>> to='jul...@im.example.com'
>> version='1.0'
>> xml:lang='en'
>> xmlns='jabber:client'
>> xmlns:stream='http://etherx.jabber.org/streams'>
>>
>> The receiving entity also MUST send stream features to the initiating
>> entity. The stream features SHOULD include an advertisement for
>> support of SASL negotiation, i.e., a <mechanisms/> element qualified
>> by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. Typically there
>> are only three cases in which support for SASL negotiation would not
>> be advertised here:
>>
>> o TLS negotiation needs to happen before SASL can be offered (i.e.,
>> TLS is required and the receiving entity is responding to the very
>> first initial stream header it has received for this connection
>> attempt).
>>
>> o SASL negotiation is impossible for a server-to-server connection
>> (i.e., the initiating server has not provided a certificate that
>> would enable strong authentication and therefore the receiving
>> server is falling back to weak identity verification using the
>> Server Dialback protocol [XEP-0220]).
>>
>> o SASL has already been negotiated (i.e., the receiving entity is
>> responding to an initial stream header sent as a stream restart
>> after successful SASL negotiation).
>>
>> [...]
>>
>> ###
>>
> Great.
>
>
>>> s6.4.2, last para: '... the server SHOULD discard the ongoing handshake...':
>>> What happens if the server (receiving entity) chooses not to
>>> comply with the new proposed SASL mechanism choice?
>>
>> That paragraph has changed in response to IESG feedback and subsequent WG
>> discussion. In my working copy it now reads:
>>
>> If the initiating entity subsequently sends another <auth/> element
>> and the ongoing authentication handshake has not yet completed, the
>> server MUST discard the ongoing handshake and MUST process a new
>> handshake for the subsequently requested SASL mechanism.
>>
> Fine.
>
>
>>> s6.4.5, paras 4 and 6: 'SHOULD close the stream': What would enity do
>>> instead?
>>
>> Return a stream error, but that's not very friendly because the initiating
>> entity hasn't really violated any rules, it's just that authentication has
>> failed.
I looked at this a bit more yesterday and realized that my reply was
wrong. You raised a point about two paragraphs. The first one applies to
the initiating entity, the second to the receiving entity. I think the
proper handling is different in those two cases. My working copy now has:
If the initiating entity attempts a reasonable number of retries with
the same SASL mechanism and all attempts fail, it MAY fall back to
the next mechanism in its ordered list by sending a new <auth/>
request to the receiving entity, thus starting a new handshake for
that authentication mechanism. If all handshakes fail and there are
no remaining mechanisms in the initiating entity's list of supported
and acceptable mechanisms, the initiating entity SHOULD simply close
the stream as described under Section 4.4 (instead of waiting for the
stream to time out).
and:
Implementation Note: For server-to-server streams, if the
receiving entity cannot offer the SASL EXTERNAL mechanism or any
other SASL mechanism based on the security context established
during TLS negotiation, the receiving entity MAY attempt to
complete weak identity verification using the Server Dialback
protocol [XEP-0220]; however, if according to local service
policies weak identity verification is insufficient then the
receiving entity SHOULD instead close the stream with a <policy-
violation/> stream error (Section 4.9.3.14) instead of waiting for
the stream to time out.
> Thinking a bit more about what you have written about stream closing and
> about SErver Dialback elsewhere, two points come to mind:
> 1) If this is a server-to-server connection, is fallback to Server
> Dialback allowed at this point?
Probably. However, I think that the more usual case is that the
receiving server would not offer SASL at all after the post-TLS restart,
insteading offering only dialback. The behavior here is to some extent
still being worked out through experimentation in the developer
community. I expect that we will be able to make a more definitive
recommendation in the next revision (3920ter) after another year or two
of implementation and deployment experience, interop testing, etc.
> 2) Presumably this ought to be a tidy close down, sending </stream> and
> doing proper TLS shutdown rather than a peremptory termination of the
> TCP - a pointer to s4.4 would help.
For the second scenario (receiving entity), yes. See corrected text above.
>>> s6.4.6, para 1: The two SHOULDs in this paragraph ought to be MUSTs. (if
>>> there is
>>> a 'from' address then the receiving entity MUST do the correlation - what
>>> else
>>> could it do? If it does the match and they don't match, what would do other
>>> than
>>> termionate the attempt?)
>>
>> We don't place a great deal of trust in the 'from' address that is sent
>> before confidentiality and integrity are in place. What if the initial
>> 'from' was tampered with, but the SASL exchange succeeds anyway? In fact we
>> might consider changing the second SHOULD to MAY for that very reason,
>> although I think SHOULD is probably fine.
>
> So this is really a matter of policy: On that basis I think both
> SHOULDs ought to be RECOMMENDED.
See above regarding RFC 2119 keywords.
>>> s8.1.2.1, item 2; also s10.5.1 and s10.5.2: s8.1.2.1, item 2 appears to
>>> introduce
>>> the idea that the <domainname> is the 'bare JID' of a server. This concept
>>> does
>>> not appear anywhere else in this document (or from a brief Google search
>>> elsewhere).
>>> It was not used in RFC 3920. It also doesn't match the definition of Bare
>>> JID
>>> in
>>> s10.5.3.2. Previously in this document this was known as the
>>> 'hostname'. I think this is probably an error. However s10.5.1 refers to a
>>> 'Mere Domain' as a JID and s10.5.2 to a <domain/resourcepart> as a JID.
>>> This
>>> seems
>>> rather inconsistent.
>>
>> The word "bare" is missing from section 4.2.6:
>>
>> For server-to-server communication, the initiating server's bare JID
>> (<domainpart>)...
>>
>> Historically, we referred to bare JID as <localp...@domainpart> and full JID
>> as <localp...@domainpart/resourcepart>, but we didn't have good terms for
>> <domainpart> vs. <domainpart/resourcepart> (not that anyone really uses the
>> latter form). Thus we borrowed the terms bare JID and full JID for servers,
>> as well.
>>
>> You make a good point about the section names. I suggest changing them to:
>>
>> 10.5. Local Domain
>> 10.5.1. domainpart
>> 10.5.2. domainpart/resourcepart
>> 10.5.3. localp...@domainpart
>> 10.5.3.1. No Such User
>> 10.5.3.2. User Exists
>> 10.5.4. localp...@domainpart/resourcepart
>>
> All sorted now!
>
>>> s8.1.2.1, items 2 and 4: As written, both items refer to stanzas 'generated
>>> by the
>>> server'. I take it that the distinction is that item 2 refers to messages
>>> from the
>>> server that are not generated by the server as a proxy for the client
>>> account
>>> but
>>> are some sort of generic control message or the like, whereas item 4 refers
>>> to
>>> server
>>> generated messages that are generated by the server as such a proxy for the
>>> client
>>> account. The wording is somewhat confusing at present. Presumably the lack
>>> of a
>>> 'from' attribute is intended to distinguish item 1 messages from item 4
>>> messages -
>>> this could be spelt out more positively if this is cotrrect.
>>
>> I suggest the following tweaked text:
>>
>> 2. When the server generates a stanza on its own behalf for delivery
>> to the client from the server itself, the stanza MUST include a
>> 'from' attribute whose value is the bare JID (i.e., <domainpart>)
>> of the server as agreed upon during stream negotiation (e.g.,
>> based on the 'to' attribute of the initial stream header).
>>
>> and:
>>
>> 4. A server MUST NOT send to the client a stanza without a 'from'
>> attribute if the stanza was not generated by the server on its
>> own behalf (e.g., if it was generated by another client or
>> another server and the server is merely delivering it to the
>> client on behalf of some other entity); therefore, when a client
>> receives a stanza that does not include a 'from' attribute, it
>> MUST assume that the stanza is from the user's account on the
>> server.
>>
> Agreed.
>
>>> s13.7.1.1. Both instances of item 4: 'The signatureAlgorithm SHOULD be the
>>> PKCS #1 version 1.5 signature algorithm with SHA-256 as defined by
>>> [PKIX-ALGO].':
>>
>> The issuing entity (typically a CA) can use a stronger signature algorithm
>> if it pleases.
>>
>>> What happens if it isn't?
>>
>> I don't see an interoperability issue here -- we're trying to provide a
>> baseline for certificate issuers, but naturally CAs might choose stronger
>> signature algorithms in the future.
>
> How about 'It is RECOMMENDED that the signatureAlgorithm is (what you
> have) or a stronger algorithm.'
Changed to:
4. The signatureAlgorithm SHOULD be the PKCS #1 version 1.5
signature algorithm with SHA-256 as defined by [PKIX-ALGO], or a
strong algorithm if available.
>>> s13.7.1.1: First item 5: 'The certificate SHOULD include an Authority
>>> Information Access (AIA) extension that specifies the address of an Online
>>> Certificate Status Protocol [OCSP] responder.'
>>> What happens if it doesn't?
>>
>> Then entities checking the certificate might need to fall back on CRLs.
>
> Would someone skilled in the art know this? Probably?
Yesterday I had changed it to:
5. The certificate SHOULD include an Authority Information Access
(AIA) extension that specifies the address of an Online
Certificate Status Protocol [OCSP] responder (if not, a relying
party would need to fall back on the use of Certificate
Revocation Lists (CRLs) as described in [PKIX]).
>>> s13.9.5 and s15: The requirement for support of TLS-NEG if TLS Renegotiation
>>> is to be allowed
>>> should be mentioned here.
>>
>> We could copy the last sentence of Section 5.3.5:
>>
>> Support for TLS renegotiation is strictly OPTIONAL. However,
>> implementations that support TLS renegotiation MUST implement and use
>> the TLS Renegotiation Extension [TLS-NEG].
>>
> Agreed (and done).
>
>>> This is also a conformance requirement.
>>
>> Section 15 does not include features that are optional.
>>
> OK
>
>>> s14: I seem to remember that giving a working group as a registrant contact
>>> for an URI is deprecated as it is likely to go out of existence fairly
>>> shortly.
>>
>> Good point, I'll change those to IESG.
>>
> Need to fix the email addresses as well.
Yep, done.
>>> Nits/editorial comments:
>>>
>>>
>>> s3.2.1, bullet labeled '5': 'The initiating entity uses the IP
>>> address(es) from the first successfully resolved hostname...': 'first'
>>> implies that it depends on how fast the answers come back. Presumably
>>> what is wanted is the IP address of the highest priority SRV record that
>>> is successfully resolved, maybe subject to some local policies?
>>
>> Good catch. I think we can change this to:
>>
>> "...from the successfully resolved hostname..."
>>
>> Where "success" is measured in the terms of the prior steps.
>
> -20 is fine.
>
>>
>>> s3.2.1,bullets labelled '3' and '8': Bullet 3 suggests that the s3.2.2
>>> fallaback process 'SHOULD' be used whereas bullet 8 has an implicit MAY
>>> (that might be better if was explicit). Why the distinction?
>>> [Presumably, having read on, there is little point in trying the first
>>> possibility in the defaults if the initiating entity has already tried
>>> the default port, but the alternatives might still work.] Section 3.2.2
>>> could mention that there is no point in trying the default ports if they
>>> were already tried under s3.2.1.
>>
>> There's a difference here between failure in the case when there are SRV
>> records, and no SRV records at all. If the DNS admin has configured SRV
>> records but they're just wrong or result in failed lookups, I think the
>> fallback is not a good idea (I've received feedback about this offlist since
>> -19 was published as well) -- this can result in some strange cases of
>> one-way connections in server-to-server scenarios. Thus I think this is
>> correct:
>>
>> 3. If a response is received, it will contain one or more
>> combinations of a port and hostname, each of which is weighted
>> and prioritized as described in [DNS-SRV]. However, if the
>> result of the SRV lookup is a single resource record with a
>> Target of ".", i.e. the root domain, then the initiating entity
>> MUST abort SRV processing at this point.
>>
>> and:
>>
>> 8. If the initiating entity receives a response to its SRV query but
>> it is not able to establish an XMPP connection using the data
>> received in the response, it SHOULD NOT attempt the fallback
>> process described in the next section (this helps to prevent a
>> state mismatch between inbound and outbound connections).
>>
>> 9. If the initiating entity does not receive a response to its SRV
>> query, it SHOULD attempt the fallback process described in the
>> next section.
>>
>>> s3.2.2: A pointer to s15.7 where the default port numbers are registered
>>> would be useful.
>>
>> Agreed. Changed to:
>>
>> The fallback process SHOULD be a normal "A" or "AAAA" address record
>> resolution to determine the IPv4 or IPv6 address of the origin
>> domain, where the port used is the "xmpp-client" port of 5222 for
>> client-to-server connections or the "xmpp-server" port of 5269 for
>> server-to-server connections (these are the default ports as
>> registered with the IANA; see Section 14.7).
>>
> New version in -20 looks fine.
>
>>> s3.2.4: Where is the appropriate XML stanza for defining add-on services
>>> defined?
>>
>> If by "defining" you mean "communicating with", the answer is that it
>> depends on the application. For XMPP groupchat services of the kind used at
>> IETF meetings, the protocol is defined here:
>>
>> http://xmpp.org/extensions/xep-0045.html
>>
>> There is no appropriate XML stanza for *defining* add-on services. If only
>> developing protocol extensions were that easy... :)
>
> I think I was reading more into what was said here than I think is
> actually said. I presume that what is implied by 'appropriate' is that
> the 'to' attribute points to the the domain name used for the server for
> the add-on service. My mind was running on extra first level stanza
> types 'appropriate' for the add-on service.
>
>
> The rest are all fine.
Excellent.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
