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

[Matt Miller]

On Nov 14, 2013, at 10:43 AM, Ralf Skyper Kaiser <skyper at thc.org> wrote:

> 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).
> 

No, it's really just the root key everyone places trust in; each other key is signed by the next key up in the chain.

For the root key, there are several avenues to get a copy of it, which means you have several avenues to verify the trust, not just apply the blind trust of a leap of faith.

> 
> 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. 
> 

You keep using the word "secure" as some sort of absolute value.  I don't think it means what you think it does.

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

Pinning -- whether SSH, HTTPS, or otherwise -- has a bootstrap problem.  Solving that bootstrap problem is really hard.  What you are saying here is that users MUST rely on a leap of faith.  Frankly, I don't find that leap of faith acceptable.  As weak as the CA model is for X.509, it seems better than a leap of faith.  The DANE/DNSSEC model seems better yet.

Once you have the initial trust, I do think key pinning is worthwhile.  Once you have the initial trust.

> 
> >
> > 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.
> 

All it takes is one tech-wizard with a distribution channel.

> 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.
> 

I see no such consensus.


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://www.jabber.org/jdev/attachments/20131114/c245a5ef/attachment-0001.pgp>