[jdev] manifesto 0.4

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/13 8:36 AM, Yann Leboulanger wrote:
> On 10/30/2013 01:21 AM, Mathieu Pasquet wrote:
>> On Tue, Oct 29, 2013 at 05:09:32PM -0600, Peter Saint-Andre
>> wrote:
>>> 
>>> I just updated the encryption manifesto to incorporate feedback
>>> and clarify a few points:
>>> 
>>> https://github.com/stpeter/manifesto/blob/master/manifesto.txt
>>> 
>>> Your feedback (and signatures!) matter.
>>> 
>>> Peter
>>> 
>>> - -- Peter Saint-Andre https://stpeter.im/
>>> 
>> 
>> Hi,

Hi Yann!

BTW thanks for Gajim -- I've been using it on my new Linux laptop and
I might send you some patches before long. ;-)

>> Before signing the manifesto as a software developer, there are a
>> few things that are unclear and I’m not sure we can commit to 
>> this just yet:
>> 
>> Dropping SSLv2 is all good and I’m not even sure why SSLv2 was 
>> supported initially (doesn’t xmpp appear after SSLv3 was
>> standardized?), but dropping SSLv3, while also a good idea, might
>> cause issues with lots of servers (not naming legacy ejabberd or
>> openfire under old debian or centos). Hopefully, we have some
>> time to wake up some admins before the dates set in the
>> manifesto, but I hope the test days will help troubleshooting the
>> ones that don’t get the memo.

One point of the test days is to find out what happens. Based on that
experience, we might either weaken some of the requirements (although
as I noted the TLS 1.0 spec was published in 1999!) or try to push
forward with stronger security.

>> Do we need, to be consistent, to disable the protocol but
>> indicate to the user he will need to perform an extra action to
>> be able to connect, or do we need to make the connection
>> impossible in any case?

IMHO it's usually not a great idea to give the user insecure options. :)

>> I find the other points sensible, so I have nothing to add,
>> except maybe separating clearly clients & server requirements.

I started to define things that way, but there was so much overlap
that I tried to make it easier to read by simplifying the text. I'm
not wedded to the way the document is structured now.

> I'd also would like some clarification about removing plain
> connection. In some situation (you have a local server for ex) the
> server can allow only non-secure connections to prevent memory
> consumption. So should we really disable plain connection or just
> disable it by default, and require some user advanced configuration
> to enable it?

As the text is written right now (0.4), requiring channel encryption
is something that service operators who sign the manifesto commit to.
Software developers commit only to supporting channel encryption and
preferring the latest TLS version, cipher suites with forward secrecy,
etc. I do think disabling unencrypted streams is a smart default. I
don't particularly want to tell client developers how to (or whether
to) allow a cleartext connection (e.g., an advanced user setting).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJScTofAAoJEOoGpJErxa2pTNMQAKmcba17IkHdnW8sVGhtR1Yu
Hs4+I+so9zgXWnHIaaLwpXYM1zNTd0lIyTy2k4WJVFBqD+hlVUp9T8tXIqTS+5dJ
bP2J9Hb5bm4oekv30TJuAsM/PLAnFkpmztwTlwQoP0lMhe8Z/ZllsL7w8udhfV0c
kJwk8iQFwfOi0jqgCX9BCBAS0/mCFvdfDUcJvKp2KZuTuuiIHE9BMjlUmcxbMfCJ
4sLqkDY11urVUtTmqajjIwbZmrdzGqJu/AOvXtU+pKgZzj8GCda6kbOOGqhceG92
XafLunFjvCLNP0jfYcsw/NOJUSqqnuOTgOB/J6+c1nxtxqw2toFIE60/2E9hYsEP
jimIe2RVcoDBOHsTieVaE5sIZhbSbCasdXFRZ9yFQvUjxTehUqwrzilq4LT+UfOQ
ExbPeIrvVPRmpHHNhP+NhhTMzgfWA03QcW0158Zqmk3QBJzAjXzuShJ4gsil4J+x
KKabJqBHauRVj/NRVxBsE1M1xg9LE09yWeN5PjDa/jKZXZry76kBT+4I9x1DQydq
vyJInhSJ1dcbJ14kbYSQqyEeAaJRtw+EOp//10aalUpbE7wcGWN58gXnuHTfmA/q
Mwif7ffE5oYMSl1Wozp8WPRyLqFXlpq4f4dMMXxPYNvZGnKV2z6+2E+1pz5qhCxt
A1y+OtvAZ6EhyPlLdffr
=N3Pq
-----END PGP SIGNATURE-----