[Security] PGP (XEP-0027)
dmeyer at tzi.de
Wed Jun 3 04:35:03 CDT 2009
Justin Karneges wrote:
> I believe the consensus is that we should support passwords, X.509, and PGP.
> So don't worry, nobody's getting left out. :) Even the latest security spec,
> draft-meyer-xmpp-e2e-encryption-01, covers all three cases.
> I do like the suggestion of generating a self-signed X.509 certificate on the
> fly and protecting it with a password somehow. This way, every existing TLS
> library and language binding can be used to implement password-secured
That was the basic idea. Reuse existing technology
> In contrast, draft-meyer-xmpp-e2e-encryption-01 specifies that passwords
> should be used natively in TLS, via the SRP extension. This approach is
> ideal from a protocol perspective, but comes with a high cost: developers may
> need to rework/switch TLS libraries.
Yes. That is some sort of problem. Another idea would be to use
something else inside 'security-info' to verify the certificates after
the TLS handshake if they are not known. This requires some sort of
channel bindings. The good idea to use the TLS Finished messages have
the same problem as SRP since it requires support in the TLS lib. A
different idea is to use the certificates in the channel binding
process: password = sha1(cert1 + cert2 + user password)
It is possible to use SRP outside TLS for the channel bindings. As
already pointed out, my understanding is that SCRAM is not secure and
the client in the role of the TLS server can run a dictionary
attack. What we need it a channel binding SASL method based on SRP.
> In my opinion, this is not XMPP's battle. I think being able to use
> "off the shelf" TLS libraries is a noble goal, and one we should
> choose over protocol purity.
Agreed. TLS-SRP makes it easy to specify but I'm open to other
solutions -- IETF solutions, not self-made.
Early to rise, early to bed, makes a man healthy, wealthy and dead.
-- Terry Pratchett, "The Light Fantastic"
More information about the Security