[Security] TLS Certificates Verification (summary)

Dirk Meyer dmeyer at tzi.de
Wed Aug 20 05:46:27 CDT 2008

Johansson Olle E wrote:
>>> 3) Clients may be behind NAT, so even a client-to-client direct
>>> session may need help from a server (proxy). This will have to be
>>> considered.
>> This is a non-issue - we have Jingle, so we have the ability to
>> negotiate various channels, at least one of which (IBB) will work
>> through any amount of NATs and firewalling, albeit at a cost of
>> efficiency and ugliness. Really, this whole debate about IBB vs NATs
>> vs whatever is immaterial; we have Jingle specifically to solve all
>> these problems, and it passes the buck to ICE-TCP et al to solve the
>> tricky cases.
> After spending many years with SIP and NAT traversal, I know that we
> will still need NAT traversal proxys, ICE/STUN is just a discovery
> service. And considering a possible future with IPv4 and IPv6, there
> will be proxys there too. Any solution has to work with an unknown or
> wellidentified point in the middle.

The c2c code just uses jingle. That is all we should care about at
this point. With IBB as fallback we have the wellidentified point in
the middle (the xmpp server). TCP-ICE is a must have for the future,
TURN could replace the XMPP SOCKS5 solution, but it does not matter at
this pount. Jingle takes care that we have some sort of end to end
connection. IBB also works together with BOSH ... XMPP over IBB over
XMPP over HTTP sounds a bit strange but is a working solution.

>>> 5) Not all clients are human. We need solutions, but maybe not one
>>> solution, for
>>>    - human clients on some sort of computer
>>>    - bots with a delegation from a human (set-top-boxes)
>>>    - applications (XMPP is used as middleware)
>> For reasons concerning the retention of my santity, at least, I'd
>> prefer these to be as common as possible.
> Me too!
> I think we have to separate the technichal solution from implementor's
> guidelines. The guidelines could talk about using USB sticks, propose
> user interaction and other things that help those who write the
> interface in the server and the client. We need to make sure that all
> clients and servers share the same terminology. 

Yes. IMHO we should start with the question the thread started with.
We have a connection (doesn't matter how we got it) and we want to
open a verified TLS layer. CA signed certificate, self-signed
certificates, web of trust, TLS-SRP. These seems to be the keywords to
solve the problem. After we do that we may need users to remember
passwords and save keys. How we can do that in a userfriendly way is
step 2. But it does not hurt to keep step 2 in mind from time to
time to not end up with users comparing key fingerprints.


Oh Lord give me patience...  NOW!

More information about the Security mailing list