[jdev] https://github.com/stpeter/manifesto and additional ideas

Winfried Tilanus winfried at tilanus.com
Fri Nov 15 10:26:24 UTC 2013

On 14-11-13 18:47, Ralf Skyper Kaiser wrote:


> d. How is the jabber server admin in control when everyone has to trust
> the master root key and all subsequent keys up to the sub domain of the
> jabber server? That's not in the control of the jabber admin.

Please take some time to study DNSSEC before making statements like this.

Lets assume an evil empire that wishes to execute a man in the middle

In the current situation that evil empire has to compromise:
- one of the hundreds of CA that are accepted by your client
- the connection between your client and the server
And the man in the middle attack is a fact. The only way to stop it, is
by telling al the clients individually to not trust that CA any more.
That is totally out of control of the jabber admin.

If you link the certificate to DNSSEC (like DANE does) then that evil
empire has to compromise:
- exactly the register that signed the domain of the jabber server, no
other register nor a register lower in the tree will work
- the connection between your client and the server
So it will be quite a bit harder for the evil empire to do a man in the
middle attack: now it is not enough any more to compromise one of some
hundreds of CA's to do a MIM against everybody, the evil empire now has
to compromise exactly the right register from a group of some hundreds
of thousands registers to do the MIM. A jabber admin can circumvent such
an attack very easily: just move the domain to an other register. So the
admin has lots of control on this.
If the evil empire also decides to compromises the TLD register, to
avoid moving the domain to a register that is not compromised, then that
would be very visible and easy to detect. So compromising other chunks
of the DNSSEC chain then the endpoint would not help the evil empire out.

Every security system can be compromised. But DNSSEC is far better then
what we have right now.

Then to the certificate pinning: It has two problems:
- It is not very user friendly, because it requires the user to judge if
a change in the certificate is suspect or not.
- There is no way to tell if the first certificate you accept is
compromised or not. So you might pin a compromised certificate.

Still certificate pinning can help to detect and protect against MIM
attacks. (That is how the Iranian eavesdropping program was detected, by
a *security expert* who did certificate pinning).

Now take a look at the manifesto. It states:

 "provide user or administrative interfaces showing:
  o a warning about any changes to a server's certificate"

that last point IS certificate pinning.

So I really don't understand the crusade you are undertaking here: first
of all the certificate pinning you plea for, is already in the
manifesto. Secondly the proposal of the manifesto also fixes one of the
problems of certificate pinning, not perfectly but with the strongest
mechanism we have available right now. You should be totally happy with
the manifesto and sign it right away!


More information about the JDev mailing list