[Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

Dave Cridland dave at cridland.net
Thu Aug 15 20:16:30 UTC 2013


On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade <thijs at xnyhps.nl> wrote:

> Both the server's and the client's certificate are sent in plain during the
> handshake. This means that any id-on-xmppAddr attribute, common name field
> or
> any other personal info on the certificate will be visible to any passive
> observer of the stream. Every client I've used tries to avoid leaking your
> identity before TLS is active (no 'from' attribute on the initial stream)
> and
> this could break that.
>
> Even when a user is using a certificate with no personally identifiable
> information at all, just by looking at the public key an observer could
> try to
> correlate different connections to the same account.
>
>
Yes, but I don't think that's a particular point in mind with XEP-0178, or
indeed XMPP in general.


> In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS
> renegotiation
> as a way to protect the client's certificate if it's known to be private. I
> guess this would work, though I'm not sure how well-supported that is.
>
>
Hmmm... I know at least some implementations might struggle. You'd have two
negotiations, and you'd have to hope that the server looked at the one you
wanted.


> I think it would be good if XEP-0178 at least mentioned that the
> certificate is
> sent in plain and pointed to §5.1.3 for a workaround.
>

I'd much rather we investigated the practical implications - '178 is
intended as best practice, so  it'd be nice to know it worked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130815/a39fbdf2/attachment.html>


More information about the Standards mailing list