On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade <[email protected]> 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.
