Thanks, Elwyn. Replies inline, areas of agreement elided. [ cc'ing [email protected] ]
On 12/14/10 6:56 AM, Elwyn Davies wrote:
>
> On Tue, 2010-12-14 at 05:49 -0700, Peter Saint-Andre wrote:
>>
>> On 12/10/10 2:53 PM, Peter Saint-Andre wrote:
>>>
>>> On 12/10/10 11:18 AM, Elwyn Davies wrote:
>>>>
>>>> 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)
>
> The wording in this section is still slightly confusing because of the
> apparently conflicting SHOULD NOTs in the note and the later
> SHOULD/MUST. I was running on the lines that the SHOULD NOT only
> affected the client-server case, but that is clearly not what is
> intended. Perhaps the thing to do is to add an additional sentence to
> the Note: 'The requirements for inclusion of 'from' addresses in the
> rest of this section apply to cases where a security layer is not used
> and to the stream headers used when restarting the stream after the
> security layer has been negotiated.'
In response to IESG feedback from Robert Sparks, I have changed this to:
###
4.7.1. from
The 'from' attribute specifies an XMPP identity of the entity sending
the stream element.
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 <localp...@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 General 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.
[...]
For initial stream headers in server-to-server communication, the
'from' attribute is one of the configured FQDNs of the server, i.e.,
a JID of the form <domainpart>. The initiating server might have
more than one XMPP identity, e.g., in the case of a server that
provides virtual hosting, so it will need to choose an identity that
is associated with this output stream (e.g., based on the 'to'
attribute of the stanza that triggered the stream negotiation
attempt). Because a server is a "public entity" on the XMPP network,
it MUST include the 'from' attribute after the confidentiality and
integrity of the stream are protected via TLS or an equivalent
security layer.
[...]
###
Robert said that works for him, so hopefully it clarifies things for
you, too.
>>>> 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.
>>>
>>> ###
> It's a long time since I read RFC 2119 :-(
>
> I was thinking of the subtle distinction in common usage between should,
> which in my book implies a degree of obligation greater than
> recommended. Given 2119 I guess it makes no difference which one you
> use.
I think that's right. The capitalized keywords from RFC 2119 are not
normal English. :)
>>>> 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.
>>>
> The transport area tend to get riled about things that might cause
> congestion.. but if they aren't complaining I suppose its OK.
It's worth considering, and I'll ask the Transport ADs for advice. But
in my experience the real impact in on the server (big CPU hit on
restart), not the network.
>>>> 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.
> That case is clear. After careful reading I got the impression that if
> the server itself sent messages (such as relating to the account) that
> were locally generated by the server and sent them back to the client
> then it was obliged to mark them with the client's preferred language
> even if this made no sense 'cos the server couldn't handle the preferred
> language. Maybe this is a non-existent case.
I think it a non-existent issue, but I'll look at the text again to make
sure it's clear.
>>>> 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).
> OK - leave it as it is.
Ack.
>>>> s5.2: SHOULD -> HIGHLY RECOMMENDED
>>>
>>> there is no HIGHLY RECOMMENDED in RFC 2119. :) I think "SHOULD" is fine.
> OK. Same point as before on SHOULD/RECOMMENDED.
Yep. Same point about the non-English character of RFC 2119 terms. :)
>>>> 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).
> Good.
OK, thanks.
I'm going to push out a revised I-D (version -21) now...
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
