Johansson Olle E wrote:
> Ok, let's use this thread and subject for that discussion and try to
> summarize where we are.
We have "XEP-0174: Serverless Messaging" and "XEP-0247: Jingle XML
Streams" to open a e2e connection. How this is done is up to Jingle
out of scope for this subthread. On top of that stream we use
"XEP-0246: End-to-End XML Streams". In this step we use starttls to
secure the connection. This is the scenario for this summary.
1. Enterprise use case when XMPP is used as middleware: TLS uses
certificates signed by a CA. No human interaction needed except
providing the certificates. It is complicated but IMHO the way a
company would use e2e.
2. For end-users like my mother a CA is too complex. Even the concept
is kind of strange why you trust someone you do not know. This
results in clients having self-signed certificates.
3. RFC 5054 SRP can be used to set TLS without valid certificates. It
requires a username and a password. We do not share a username
between client so this has to be set to some simple default. The
password is the shared secret.
4. After SRP we can rehandshake and now know the public key and
fingerprint of the peers certificate. Store it for later use.
5. Bots may have predefined secrets, e.g. printed on the back of the
set-top box.
6. A user may have different certificates for each client. He could
sign each of these certificates with a CA he created, but again:
too complicated. We could update XEP-0189: "Public Key Publishing"
to publish all client keys of a user signed by the user key.
7. We also could create some sort of web of trust based on XEP-189. If
I trust you and just trust Peter maybe I do not want to go through
SRP and just believe it is Peter because you said so.
8. If you loose the private part of your user key you are lost.
Guidelines how to help the user not to loose it are out of the
scope of this subthread. In this subthread we know we have the user
key.
Open Issues:
1. To to update a certificate? They have an expire date so I need
create a new self-signed certificate from time to time. Maybe
XEP-189 can help here.
SRP Usage:
Maybe I'm reading the doc wrong and I have no idea if openssl and
friends support the following guidelines. The question is: when to use
SRP and when to use public keys.
1. Sending ClientHello
a. If I connect to someone I do not know, I only add SRP ciphers. I
will refuse anything except SRP.
b. If I know the other side I also add "normal" ciphers.
c. If I am a bot and know the other side I only provide normal
ciphers and hope that it will work.
2. When I get a request with SRP and normal ciphers I can choose.
a. If I know the peer based on the JID I could continue normal TLS
(Question: Is this possible? I do not see anything against it in
the RFS).
b. When I do not know the users public key, I want to use SRP and
send unknown_psk_identity as described in 2.5.1.2. of the
RFC. We start again (on TLS level) and the users have to provide
a key.
3. When I get a request without SRP and I can not verify the
certificate TLS fails.
Dirk
--
Computer analyst to programmer: "You start coding. I'll go
find out what they want."
