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

[Stef Walter <[e-mail]>]

On 03/16/2011 10:44 AM, Kevin Smith wrote:
> On Wed, Mar 16, 2011 at 9:40 AM, Stef Walter <[e-mail]> wrote:
>> From a security perspective the hardcoded or configured hostname is user
>> input and can be used in identity checks. So client app developers have
>> two options:
>>
>>  * Throwing up a "cop out" certificate dialog and tossing the entire
>>   security decision in the lap of the user.
>>
>>  * Using all the user's input (not just the JID) to generate reference
>>   identifiers to use to verify the certificate.
>>
>> If these were corner cases, and 99% of users would never run into this,
>> then I'd tend to agree with you, but this is a widely deployed
>> configuration on virtually hosted XMPP servers.
> 
> This is mixing two ideas - yes, GTalk has many many hosted domains and
> isn't presenting 'valid' certificates for them. However, in none of
> these cases should the user be specifying a hard-coded hostname - that
> just implies that their DNS setup is broken.
> 
> Virtual hosting - common
> Manually specifying connection hosts - rare.

I wish it was rare, but all the documentation that users follow to setup
their Google Talk accounts talk about manually specifying the connection
host:

http://www.google.com/support/talk/bin/answer.py?answer=24076
http://www.google.com/support/talk/bin/answer.py?hl=en&answer=24073
http://www.google.com/support/talk/bin/answer.py?hl=en&answer=24074
... and so on ...

Also in many clients the user selects 'Google Talk' as the type of
account, and therefore the client knows that the client is expecting to
connecting to talk.google.com and the client manually uses this as a
reference identifier.

I'm not holding this up as some example of a sane setup. But using
additional user input as reference identifiers is a pragmatic solution
to something that a large amount of users bump into when using XMPP + TLS.

I guess I'm okay with just leaving this annoying situation unspecified
in the RFC, and hopefully it'll go away in the future once things like
SNI is better supported, and service providers with virtual hosting get
their act together.

Until then clients meanwhile will probably continue to use the manually
specified server and user selection as a way to check certificate
identities and not follow the RFC too closely in this regard.

Cheers,

Stef