[jdev] manifesto 0.4

Peter Saint-Andre stpeter at stpeter.im
Wed Oct 30 16:55:59 UTC 2013

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 Saint-Andre

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


More information about the JDev mailing list