On Nov 14, 2013, at 10:43 AM, Ralf Skyper Kaiser <[email protected]> wrote:
> On Thu, Nov 14, 2013 at 4:49 PM, Matt Miller <[email protected]> > wrote: > > On Nov 14, 2013, at 9:34 AM, Ralf Skyper Kaiser <[email protected]> wrote: > > > > > On Thu, Nov 14, 2013 at 4:24 PM, Dave Cridland <[email protected]> wrote: > > On Thu, Nov 14, 2013 at 4:09 PM, Matt Miller <[email protected]> > > wrote: > > > > On Nov 14, 2013, at 8:33 AM, Ralf Skyper Kaiser <[email protected]> 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
