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

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

On 3/14/11 5:19 PM, Florian Zeitz wrote:
> Am 15.03.2011 00:07, schrieb Joe Hildebrand:
>> On 3/14/11 4:38 PM, "Florian Zeitz"<[e-mail]>  wrote:
>>
>>
>>> I was recently wondering something related.
>>> Do I set the 'to' attribute in the initial stream header to the JID's
>>> domainpart, or to the domain I got from a SRV lookup?
>>> 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.
>>
>> It's always the domain name the user entered, not something you get
>> from the
>> (currently untrusted) DNS.  Many servers use this name to figure out
>> which
>> certificate to give you when you Start-TLS, rather than having to rely on
>> SNI.
>>
> That is not a sufficient answer.
> Stef Walter's point, that I was trying to address, was that in some
> cases the user entered two different domains. One as part of his JID the
> other one as the domain to connect to.

I think you mean the kind of thing that is explained, in depth, in
draft-saintandre-tls-server-id-check. I encourage anyone who has
questions about these matters to please re-read that spec, because it
discusses these matters in great detail.

So yes, it is true that in some circumstances a user might configure his
IM client with two things:

1. The domain name of the application service, which is the domainpart
of his JID, such as [e-mail] => montague.lit; this is the
"source domain".

2. A "hardcoded" hostname that he has explicitly assocated with the
domainpart of your JID, such as apps.shakespeare.lit; this is the
"target domain".

However, for the purposes of checking the identity of the application
service when connecting via TLS, Romeo's client would check to see that
the service presents a certificate that says it is "montague.lit"
(unless he overrides the checks or explicitly approve of connecting to
"apps.shakesepeare.lit").

Please understand that 99% of users will never see such a configuration
option and that they don't know anything about apps.shakespeare.lit or
some special hostname that they're connecting to -- all that they know
is that they're trying to connect to montague.lit (if they even know
this, because lots of people just think that they're trying to connect
to "Shakespeare" or even "that IM thing" -- if you doubt it, I recommend
that you run your own public IM service, because it can be quite
enlightening).

> Both are certainly valid options for checking against.

Are they? From a user perspective, is montague.lit (the source domain)
just as valid as apps.shakespeare.lit (the target domain)? Does the
typical user understand that kind of delegation arrangement? Again, I
suggest that they don't.

> My reasoning was that since you have to use the domainpart of the JID
> when doing SRV (I was not sure from reading the draft, but it seemed
> sensible), 

What else would you use?

> it seems logical to do the same when the user specified a FQDN.

In this case, if Romeo has explicitly approved of connecting to
apps.shakespeare.lit then he has "pinned" the certificate to that
domain, in which case it's fine for the server to check that identity in
addition to "montague.lit". However, in general this is not a good idea
because very few users understand the implications of such a configuration.

In any case, nothing in this message requires any changes to either
draft-ietf-xmpp-3920bis or draft-saintandre-tls-server-id-check.

Peter

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