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

Dave Cridland dave at cridland.net
Thu Nov 14 13:01:29 UTC 2013


On Thu, Nov 14, 2013 at 12:53 PM, Ralf Skyper Kaiser <skyper at thc.org> wrote:

> Hi,
>
> Ideas, comments and an open discussion are welcome to include the
> following ideas in the manifesto.
>
> - Client-support for certificate pinning (including pinning of self-signed
> certificates).
>   https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
>   http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
>

I'm waiting to see how that one stabilizes before commenting. Ultimately, I
think such techniques will be handled much better by DANE.


>
> - Client Lockdown feature: Automatically sets a variety of security
> preferences
>   to "known good" settings. Once lockdown option is set the user should
> not be
>   able to change any of the 'locked' security preferences until lockdown
> is disabled
>   again (e.g. gray out the option). Lockdown includes: Do not permit
> non-OTR
>   messages, require TLS, do not permit message logging)
>
>
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.

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.


> - Client to notify server which method the client used to authenticate the
> server's
>   identity and if client is in Lockdown.
>
>
How does the server know if the client is lying or not?

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.

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


More information about the JDev mailing list