Re: [xmpp] Clarification of TLS Identity checking in draft-ietf-xmpp-3920bis

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

Sorry, I was in a hurry earlier. I've had another look at this now that
I have a bit more time...

On 3/14/11 5:30 PM, Florian Zeitz wrote:
> Am 15.03.2011 00:01, schrieb Peter Saint-Andre:
>> On 3/14/11 4:38 PM, Florian Zeitz wrote:
>>> I think there are 2 things in the draft that are actually wrong-ish:
>>> a) It currently says "The initiating entity sets its reference
>>> identifier to the 'to' address it communicates in the initial stream
>>> header". I think that is somewhat backwards. The initiating entity does
>>> not choose the domain to construct reference identifiers from based on
>>> the 'to' attribute that it set, but it sets the 'to' attribute based on
>>> the same domain it bases the reference identifiers of.
>>
>> I don't see a real difference between those two things.
>>
> It's really not a big deal. Basically currently it says that the 'to'
> attribute is said from the user input and the source domain is then set
> from the 'to' attribute. That seems like a strange layer of indirection,
> but I can certainly live with it.

In fact I think it's right as it is. Here's why:

1. First the initiating entity opens a stream to the receiving entity.
There is no security interaction yet.

2. The parties decide to negotiate TLS. Now the initiating entity
establishes its set of reference identifiers based on the source domain.

>>> b) I don't think the draft means "reference identifier" here. I think
>>> what it actually is talking about is the "source domain" that it will
>>> base reference identifiers of. I think once that is clarified the rules
>>> for building a list of reference identifiers that are in
>>> draft-saintandre-tls-server-id are sufficient.
>>
>> I think that's right, and changing "reference identifier" to "source
>> domain" is a relatively small fix. The rules about reference identifiers
>> are provided in Section 13.7.1.2.1.
>>
> I had hoped for that ;)

The right fix is:

   The initiating entity sets the source domain of its reference
                              ^^^^^^^^^^^^^^^^^^^^
   identifier to the 'to' address it communicates in the initial
   stream header...

>>> The later is certainly not sufficient as a source domain. That in turn
>>> implies (IMHO) we will always have/want to set the 'to' attribute to the
>>> JID's domainpart (and while the draft actually says to put a
>>> "domainpart" there, it is not specific on where to get that from,
>>> especially for the cases where you can't set a 'from', because you don't
>>> know the JID beforehand). I'd therefore assume you'd not use the
>>> user-entered FQDN as source domain, but I'd like some clarification on
>>> that point, too.
>>
>> Here again I don't understand the concern.
>>
>> Let's say a connected client generates a stanza for sending to
>> [e-mail]. The server strips off the localpart, throws away the
>> at-sign, and thus has montague.net as the domain to which it will try to
>> connect (i.e., perform FQDN resolution to get an IP address etc.).
>> That's the domainpart the server derives from the stanza's 'to' address.
>> Seems pretty straightforward to me, but perhaps it's not spelled out in
>> exactly that many words.
>>
> I think that example only applies to S2S connections, right?

Yes.

> Specifically I'm wondering:
> If a client connects to a server, just knowing the domain to connect to,
> but not the users JID what does it put as the 'to' attribute?

I'm still confused. What do you mean by "the client does not know the
user's JID"?

Except in rare kinds of deployments that we don't care about in this
discussion (e.g., where the localpart of the user's JID is determined by
some kind of lookup process based on information in a client
certificate), the client is always going to know that the user has, say,
an account of "romeo" at the domain "montague.lit".

> Depending on the answer to Stef Walter's original question that might be
> trivial to answer or not, it's either that very domain, or a domainpart
> that is not actually known to the client.

The client needs to know the domainpart of the user's bare JID if it
going to act on the user's behalf. It's as simple as that (except for
the rare deployments I mentioned above).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/