<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 1:01 PM, Dave Cridland <span dir="ltr"><<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Thu, Nov 14, 2013 at 12:53 PM, Ralf Skyper Kaiser <span dir="ltr"><<a href="mailto:skyper@thc.org" target="_blank">skyper@thc.org</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>Ideas, comments and an open discussion are welcome to include the<br>following ideas in the manifesto.<br>

<br>- Client-support for certificate pinning (including pinning of self-signed certificates).<br>
  <a href="https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning" target="_blank">https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning</a><br>  <a href="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08" target="_blank">http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08</a><br>


</div></div></blockquote><div><br></div></div><div>I'm waiting to see how that one stabilizes before commenting. Ultimately, I think such techniques will be handled much better by DANE.</div></div></div></div></blockquote>
<div><br></div><div>DANE requires an upgrade in infrastructure and wont happen in the immediate future (it might not happen at all).<br><br>DANE again relies on sort-off 'CA-style' trust model ...which was the problem to start with.<br>
<br></div><div>Pinning puts the trust into the hand of the server-admin, without third parties. Secure.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>  <br>- Client Lockdown feature: Automatically sets a variety of security preferences<br>  to "known good" settings. Once lockdown option is set the user should not be<br>  able to change any of the 'locked' security preferences until lockdown is disabled<br>


  again (e.g. gray out the option). Lockdown includes: Do not permit non-OTR<br>  messages, require TLS, do not permit message logging)<br><br></div></div></blockquote><div><br></div></div><div>You want the client to somehow make its options read-only? What if they got locked down in a less than optimal manner? What if they were locked down such that when a new security feature was available, the user couldn't then take advantage of it.</div>

<div><br></div><div>This also requires us to standardize the meaning of lockdown, and also standardize the options we want to be included. I really don't think this one will fly.</div></div></div></div></blockquote><div>
<br></div><div>This is a feature in the client/UI software. Sorry if this was not clear.<br><br></div><div>The developer of the software can freely decide to include the new security feature as a lockdown-default or not.<br>
<br>The lockdown feature is helpful for the normal user to configure the client securely at a time of social unrest, when used from a public terminal or when a novice user (who does not understand security, e.g. 99% of all users) wants to communicate securely.<br>
<br>Configuring any jabber client securely requires some skills and understanding of security. It also requires a certain amount of patient to navigate through and almost endless number of menus and sub-menus to enable all the security relevant features and disable the bad ones.<br>
<br>The average citizen on the other hand would be able to select 'LockDown' and trusting the software to turn on maximum security features. ("Lockdown" is more easily understood than "Do you want SSL 3.0 or TLS 1.2?").<br>
<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>- Client to notify server which method the client used to authenticate the server's<br>
  identity and if client is in Lockdown.<br><br></div></div></blockquote><div><br></div></div><div>How does the server know if the client is lying or not?</div></div></div></div></blockquote><div><br></div><div>The server does not (and that's not what this feature is about).<br>
<br></div><div>This feature prevents accidental misconfiguration or laziness of the user.<br><br></div><div>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></div><div>Users are lazy (quote). I ran a test and invalidated our server's certificate. No user should connect if he follows the security guidelines. Yet more than half of them connected instantaneously (auto-reconnect). <br>
<br>Those users configured their client not to verify the server certificate at all. Because configuring the client this way is easier than importing the ROOT CA certificate.<br><br></div><div>The lazy option is to not verify the server's certificate. The lazy option is the insecure option<br>
</div><div><br></div><div>Yes, the user can hack the client and lie about if the client has correctly verified the server cert. This would take more time and work than importing the ROOT CA certificate.<br><br>The lazy option becomes importing the ROOT CA certificate. Now the lazy option is the secure option.<br>
<br></div><div>It's the same argument why the car beeps when the driver does not put on his seat belt. Yes, the drive can hack his car and disable the beeper. But the lazy option is to put on the seat belt.<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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>As an aside, channel binding obviates the need for at least the former, since it ties in authentication with the TLS channel in such a ways that there can't be a MITM between the client and server without the authentication being broken anyway.</div>
</div></div></div></blockquote><div><br></div><div>Do you have more details on 'channel binding' for clients? This sounds interesting.<br><br></div><div>regards,<br><br>ralf<br></div></div><br></div></div>