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

[Ralf Skyper Kaiser]

On Thu, Nov 14, 2013 at 4:49 PM, Matt Miller <linuxwolf at outer-planes.net>wrote:

>
> On Nov 14, 2013, at 9:34 AM, Ralf Skyper Kaiser <skyper at thc.org> wrote:
>
> >
> > On Thu, Nov 14, 2013 at 4:24 PM, Dave Cridland <dave at cridland.net>
> wrote:
> > On Thu, Nov 14, 2013 at 4:09 PM, Matt Miller <linuxwolf at outer-planes.net>
> wrote:
> >
> > On Nov 14, 2013, at 8:33 AM, Ralf Skyper Kaiser <skyper at thc.org> wrote:
> > > Example: I'm running a private jabber server with around 200 users. I
> have strict a security guideline and currently have to trust my users to
> follow it. I trust the users to verify the server certificate against our
> own ROOT CA certificate.
> > >
> >
> > Adding a new trust anchor is just about impossible on some mobile
> platforms, and could get more difficult on more traditional ones.
> >
> >
> > DANE, of course, means that you can specify a particular private CA is
> used exclusively.
> >
> > Pinning does not require a CA at all (private or public). Why use a
> feature (DANE) that requires a CA if it is possible to have the same level
> of security with Pinning; which requires no CA, works well with self-signed
> certificates, requires no infrastructure upgrade and which puts the direct
> trust into the hands of the server-admins?
> >
> >
>
> I suggest you read [RFC6698], particularly on cert usage 3.
>

Sorry if I was not clear: DANE relies on DNSSEC which relies on a master
ROOT KEY. The DANE requested data is still authenticated with a 'sort off'
CA (e.g. the master ROOT key).

RFC6698 cert usage 3 is a good feature but does not solve the problem that
the user or admin has to trust a master ROOT KEY out of his control.

(In fact it's not just the root key that the user/admin has to trust but
all keys up to his subdomain).


> Second, certs are only as trustworthy as the person accepting them allows
> for.  Pinning only kicks in after the user somehow accepts the cert the
> first time.  If it's not a certificate issued by one of the trust anchors
> the user's client knows about (or more pedantically, that an unbroken chain
> of issuance from the end-entity certificate to an established trust
> anchor), then the user has to click a "Accept this Cert" (most likely) or
> install a new trust anchor (unlikely, and becoming more so).
>
> To mean, this means that pinning doesn't put all the trust into the hands
> of server-admins, but rather in the hands of users.
>


I should have said 'most of the trust' instead of 'all the trust'. Thanks
for checking the details.

It works for SSH (pin ssh host key on first connect). It works well. It's
secure.

It will work for jabber clients. More easily, more secure and faster
deployed than DANE.



> >
> > Actually, the lazy option is to not upgrade the client to support
> whatever private extension that supports the particular variety of lockdown
> and so on that you want in the first place.
> >
> >
> > 1. The server admin has the option to ban old clients.
> >
>
> In which case obtaining the hack becomes the lazy option.
>

Might be true for the tech-wizard but I doubt it is true for the majority
of Internet users.

I hear a lot "but the user can circumvent this security" but I do not hear
any better proposal. In the absence of a better proposal the suggested idea
is the best there is.

We have already agreed that there are these advantages _without_ any
disadvantages
1. Prevents accident misconfiguration of the client
2. Brings to jabber clients what "Private Browsing" brought to web browsers
3. Gives some information (not authentic) to the server admin which use is
in Lockdown and how the server cert was authenticated.

regards,

ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20131114/e04138ee/attachment.html>