<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 14, 2013 at 4:49 PM, Matt Miller <span dir="ltr"><<a href="mailto:linuxwolf@outer-planes.net" target="_blank">linuxwolf@outer-planes.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Nov 14, 2013, at 9:34 AM, Ralf Skyper Kaiser <<a href="mailto:skyper@thc.org">skyper@thc.org</a>> wrote:<br>
<br>
><br>
> On Thu, Nov 14, 2013 at 4:24 PM, Dave Cridland <<a href="mailto:dave@cridland.net">dave@cridland.net</a>> wrote:<br>
> On Thu, Nov 14, 2013 at 4:09 PM, Matt Miller <<a href="mailto:linuxwolf@outer-planes.net">linuxwolf@outer-planes.net</a>> wrote:<br>
><br>
> On Nov 14, 2013, at 8:33 AM, Ralf Skyper Kaiser <<a href="mailto:skyper@thc.org">skyper@thc.org</a>> wrote:<br>
> > 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.<br>

> ><br>
><br>
> Adding a new trust anchor is just about impossible on some mobile platforms, and could get more difficult on more traditional ones.<br>
><br>
><br>
> DANE, of course, means that you can specify a particular private CA is used exclusively.<br>
><br>
> 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?<br>

><br>
><br>
<br>
</div>I suggest you read [RFC6698], particularly on cert usage 3.<br></blockquote><div><br></div><div>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).<br>
<br></div><div>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.</div><br></div><div class="gmail_quote">(In fact it's not just the root key that the user/admin has to trust but all keys up to his subdomain).<br>
<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>

<br>
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.<br></blockquote><div><br></div><div><br>I should have said 'most of the trust' instead of 'all the trust'. Thanks for checking the details.<br>
<br>It works for SSH (pin ssh host key on first connect). It works well. It's secure. <br><br></div><div>It will work for jabber clients. More easily, more secure and faster deployed than DANE.<br><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> 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.<br>
><br>
><br>
> 1. The server admin has the option to ban old clients.<br>
><br>
<br>
</div>In which case obtaining the hack becomes the lazy option.<br></blockquote><div><br></div><div>Might be true for the tech-wizard but I doubt it is true for the majority of Internet users.<br><br></div><div>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.<br>
</div><br></div>We have already agreed that there are these advantages _without_ any disadvantages<br></div><div class="gmail_extra">1. Prevents accident misconfiguration of the client<br></div><div class="gmail_extra">2. Brings to jabber clients what "Private Browsing" brought to web browsers<br>
</div><div class="gmail_extra">3. Gives some information (not authentic) to the server admin which use is in Lockdown and how the server cert was authenticated.<br><br></div><div class="gmail_extra">regards,<br><br>ralf<br>
<br></div></div>