+1
>> but we
>> desperately need the equivalent of the old email "non-delivery report"
>> going back when connections are refused or non-technical users on
>> older servers are never going to even know there's anything wrong. All
>> they'll see is less people on their roster and they'll install
On 5 October 2015 at 02:04, Mike Barnes wrote:
> What we need to be doing is putting information about the quality of
> encryption used in a conversation in front of the users, and letting
> them make informed decisions, instead of fracturing the network
> invisibly.
I
. No s2s encryption no service. In those five years I had two tickets from users which tried to reach a server which was not able to encrypt. Von: Matthew WildGesendet: 05.10.2015 15:26An: XMPP Operators GroupBetreff: Re: [Operators] Please enable Forward Secrecy for your servers!On 5 October
.
- Ursprüngliche Nachricht -
Von: "Matthew Wild" <mwi...@gmail.com>
Gesendet: 05.10.2015 15:26
An: "XMPP Operators Group" <operators@xmpp.org>
Betreff: Re: [Operators] Please enable Forward Secrecy for your servers!
On 5 October 2015 at 02:04, Mike Ba
This all seems perfectly reasonable to me; if you don't have PFS
enabled ciphers, I don't understand why you'd expect to be able to be
part of the network these days.
Maybe as part of the 2016 compliance suites (which I'm in the process
of writing to propose to the XSF council, see standards@ for
Hi,
On Mon, Oct 05, 2015 at 09:45:11AM -0500, Sam Whited wrote:
> This all seems perfectly reasonable to me; if you don't have PFS
> enabled ciphers, I don't understand why you'd expect to be able to be
> part of the network these days.
I completely agree. Support for PFS ciphers is not
On 05.10.2015 at 03:04, Mike Barnes wrote:
> What we need to be doing is putting information about the quality of
> encryption used in a conversation in front of the users, and letting
> them make informed decisions, instead of fracturing the network
> invisibly.
What comes to my mind here, is
Well as it is a standard for pretty much every protocol now why should we hold it back?17:57, 5 October 2015, Mathias Ertl :Hi,On Mon, Oct 05, 2015 at 09:45:11AM -0500, Sam Whited wrote: This all seems perfectly reasonable to me; if you don't have PFS enabled ciphers, I don't
On 5 October 2015 at 14:22, Matthew Wild wrote:
> This is technically achievable using security labels
> (http://xmpp.org/extensions/xep-0258.html ), though it hasn't really
> been deployed that way on the public network, and not many clients
> support it (though Swift and
At least gmail,can't say I've blocked the others but I already can't communicate without forward secrecy.13:52, 4 October 2015, Vincent Lauton :Actually I do...10:31, 4 October 2015, Evgeny Khramtsov :Sat, 03 Oct 2015 13:40:17 +0200Vincent Lauton
Actually I do...10:31, 4 October 2015, Evgeny Khramtsov :Sat, 03 Oct 2015 13:40:17 +0200Vincent Lauton wrote: Also I meant I'll block servers that don't support any forward secrecy suitesGreat idea, LOL. Do you have gmail.com and all its hosted
Sat, 03 Oct 2015 13:40:17 +0200
Vincent Lauton wrote:
> Also I meant I'll block servers that don't support any forward
> secrecy suites
Great idea, LOL. Do you have gmail.com and all its hosted domains
blocked already? They don't have any "secrecy" at all.
What we need to be doing is putting information about the quality of
encryption used in a conversation in front of the users, and letting
them make informed decisions, instead of fracturing the network
invisibly.
Is there any defined mechanism to do this? Users are accustomed to the
little
Hey all,
After my server switch,due to the absolute unreactivity of certain
administrators,I will be explicitly looking for and blocking any servers that
do not support PFS.Some of these such as Jodo.im and exploit.im have
particularly bad security settings,customised from the get-go to a
Being that XMPP with Off-The-Record Messaging is considered secure in many
environments and that most users have low knowledge of encryption,I would tend
to disagree.And it might be,but I feel users should be able to expect the
server they sign up on will have at least current day standards in
Sat, 03 Oct 2015 11:54:44 +0200
Vincent Lauton wrote:
> These people obviously have no regard for the security and privacy of
> their users and others and refuse to acknowledge their being obsolete
> or pay attention to new XMPP specifications and standards.
These people do
+1 We already lost significant user base with Google XMPP federation
going bye-bye, don't want to make this problem worse.
On 2015-09-16 9:08 PM, Mike Barnes wrote:
I'm really hesitant to implement a massive restriction like this
precisely because it is invisible to the end user, and is just
Hi Kim - what happens from the end-user POV when that module is in
place? Will most clients reliably report that back?
I'm really hesitant to implement a massive restriction like this
precisely because it is invisible to the end user, and is just going
to lead to more people going "well, I can't
Unfortunately a majority of users use jodo.im or exploit.im,both servers that have particularily bad SSL configuration and do not support any forward secrecy ciphers.Jodo.im's SSL certificate is expired,still supports SSLv3 and does not support TLS above v1.I already enforce PFS and these are the
Hi everybody,
Just a quick reminder, this is less then a month from now:
On 2015-07-10 11:47, Mathias Ertl wrote:
> We at jabber.at would like to announce that we will exclusively support
> forward secrecy[1] enabled ciphers starting *October 1st, 2015*. Servers
> that do not support any of
Hi Mike,
On 07/10/2015 01:11 PM, Mike Barnes wrote:
Do you have any details on which client software and versions you've
tested, Mathias? I've been looking at doing this but I've been more
concerned about the client experience than s2s issues.
At jabber.ccc.de, I had (forcing Forward Secrecy
Yes, my server would be one of those who cannot reach jabber.ccc.de any
more.
I did not get around to turning it on yet, I need a software upgrade for
that.
I understand the need for extra security but enforcing it right away
without giving fellow operators time to upgrade as well will only
I second this a little bit.
In my case I need to upgrade from Debian wheezy to jessie to get PFS, so
there is more work involved. And I'd expect a decent number of servers
to be in the same situation. Jessie came out in April, so it's not brand
new. But it is still fairly recent and you can't
Hi David and all other wheezy users!
On 2015-07-27 19:22, David Mohr wrote:
In my case I need to upgrade from Debian wheezy to jessie to get PFS, so
there is more work involved. And I'd expect a decent number of servers
to be in the same situation. Jessie came out in April, so it's not brand
Had upgraded from Wheezy's ejabberd to Jessie's in a week the latter was
released and can say that it was not that hard. Now ejabberd is
relatively up-to-date and works great. The configuration format changed
to YAML, but ejabberd is shipped with a conversion tool, which converts
old config
On 2015-07-21 00:19, Jonathan Schleifer wrote:
So, 4096 bit RSA just gives you an additional 16 bits for your AES,
while doubling the number of RSA bits more than doubles the
computational overhead…
I consider this argument invalid. It's not because just additional 16
bits is wrong. Its
Am 27.07.2015 um 20:09 schrieb Mathias Ertl m...@fsinf.at:
On 2015-07-21 00:19, Jonathan Schleifer wrote:
So, 4096 bit RSA just gives you an additional 16 bits for your AES,
while doubling the number of RSA bits more than doubles the
computational overhead…
I consider this argument
Am 27.07.2015 um 21:05 schrieb Vincent Lauton vi...@darkness.su:Excuse me guys,but my server costs me 12.6$ a month,and it's offshore where powerful hardware gets more expensive.It is not a powerful server.I still manage to enforce PFS with plenty of resources to spare.SSL resources are not that
Excuse me, but i dont understand your problems, for example my public
jabber server (
https://xmpp.net/result.php?domain=jabber.plitc.eutype=client ) runs
PFS for a long time and it's just a cheap freebsd jail with always the
current prosody port ( http://www.freshports.org/net-im/prosody/ )
why not allow 2048 for now with the prerequisite that all server may move
to 4096, if we can actually agree on it. Some people may also need to
purchase new certs anyways, so at least they have a heads up.
but that's just me.. I just had a 2048 last year before renewing and just
so happened to do
Hi,
On 2015-07-27 20:58, Jonathan Schleifer wrote:
Am 27.07.2015 um 20:09 schrieb Mathias Ertl m...@fsinf.at:
On 2015-07-21 00:19, Jonathan Schleifer wrote: So, 4096 bit RSA
just gives you an additional 16 bits for your AES, while doubling
the number of RSA bits more than doubles the
I thought I saw some servers were already discriminating by cert size, mb.
On Mon, Jul 27, 2015 at 4:36 PM, Mathias Ertl m...@fsinf.at wrote:
I think we have a misunderstanding here:
On 2015-07-27 22:28, Patrick Beisler wrote:
why not allow 2048 for now with the prerequisite that all server
My certtificate has always been 4096 bit.
I think we have a misunderstanding here:
On 2015-07-27 22:28, Patrick Beisler wrote:
why not allow 2048 for now with the prerequisite that all server may
move to 4096, if we can actually agree on it. Some people may also need
to purchase new certs anyways, so at least they have a heads up.
On 21 Jul 2015, at 09:15, Jonathan Schleifer js-xmpp-operat...@webkeks.org
wrote:
Am 21.07.2015 um 09:44 schrieb David Banes da...@banes.org:
If you're serious about stopping someone with greater computational power
than you getting at your data then you should take every bit you can. But
On 21 July 2015 at 08:44, David Banes da...@banes.org wrote:
On 20 Jul 2015, at 23:19, Jonathan Schleifer
js-xmpp-operat...@webkeks.org wrote:
Am 21.07.2015 um 00:10 schrieb David Banes da...@banes.org:
On 20 Jul 2015, at 23:07, Peter Kieser pe...@kieser.ca wrote:
On 2015-07-10 2:47
On 20 Jul 2015, at 23:19, Jonathan Schleifer js-xmpp-operat...@webkeks.org
wrote:
Am 21.07.2015 um 00:10 schrieb David Banes da...@banes.org:
On 20 Jul 2015, at 23:07, Peter Kieser pe...@kieser.ca wrote:
On 2015-07-10 2:47 AM, Mathias Ertl wrote:
* Have a valid 4096 bit certificate with
Am 21.07.2015 um 00:10 schrieb David Banes da...@banes.org:
On 20 Jul 2015, at 23:07, Peter Kieser pe...@kieser.ca wrote:
On 2015-07-10 2:47 AM, Mathias Ertl wrote:
* Have a valid 4096 bit certificate with at least a sha256 signature.
4096 bit seems a bit excessive. NIST is still
On Monday 20 July 2015 23:10:21 David Banes wrote:
On 20 Jul 2015, at 23:07, Peter Kieser pe...@kieser.ca wrote:
On 2015-07-10 2:47 AM, Mathias Ertl wrote:
* Have a valid 4096 bit certificate with at least a sha256 signature.
4096 bit seems a bit excessive. NIST is still recommending
On 20 Jul 2015, at 23:07, Peter Kieser pe...@kieser.ca wrote:
On 2015-07-10 2:47 AM, Mathias Ertl wrote:
* Have a valid 4096 bit certificate with at least a sha256 signature.
4096 bit seems a bit excessive. NIST is still recommending 2048 bit from 2011
to 2030.
-Peter
I laughed
On 2015-07-10 2:47 AM, Mathias Ertl wrote:
* Have a valid 4096 bit certificate with at least a sha256 signature.
4096 bit seems a bit excessive. NIST is still recommending 2048 bit from
2011 to 2030.
-Peter
smime.p7s
Description: S/MIME Cryptographic Signature
Dear fellow operators,
We at jabber.at would like to announce that we will exclusively support
forward secrecy[1] enabled ciphers starting *October 1st, 2015*. Servers
that do not support any of those ciphers by then, will not be able to
federate with us until they upgrade.
We already tested
Dear *,
On 07/10/2015 11:47 AM, Mathias Ertl wrote:
We at jabber.at would like to announce that we will exclusively support
forward secrecy[1] enabled ciphers starting *October 1st, 2015*. Servers
that do not support any of those ciphers by then, will not be able to
federate with us until
:14
An: XMPP Operators Group operators@xmpp.org
Betreff: Re: [Operators] Please enable Forward Secrecy for your servers!
Do you have any details on which client software and versions you've
tested, Mathias? I've been looking at doing this but I've been more
concerned about the client experience
Do you have any details on which client software and versions you've
tested, Mathias? I've been looking at doing this but I've been more
concerned about the client experience than s2s issues.
You say very few users had issues - what was your sample size? It's
really hard to get in touch with a
Hi Mike,
Am 2015-07-10 um 13:11 schrieb Mike Barnes:
Do you have any details on which client software and versions you've
tested, Mathias? I've been looking at doing this but I've been more
concerned about the client experience than s2s issues.
On s2s vs. c2s: After the switch, our s2s
BarnesGesendet: 10.07.2015 13:14An: XMPP Operators GroupBetreff: Re: [Operators] Please enable Forward Secrecy for your servers!Do you have any details on which client software and versions you'vetested, Mathias? I've been looking at doing this but I've been moreconcerned about the client experience than s2s
Hi Mathias,
Happy to read this!
Cheers,
Ludovic
Le 10/07/2015 11:47, Mathias Ertl a écrit :
Dear fellow operators,
We at jabber.at would like to announce that we will exclusively support
forward secrecy[1] enabled ciphers starting *October 1st, 2015*. Servers
that do not support any of
recipient, please immediately inform
thesender and delete this mail. Any unauthorized copying, disclosure
ordistribution of this Mail is not allowed.
Von: Mike Barnes
Gesendet: 10.07.2015 13:14
An: XMPP Operators Group
Betreff: Re: [Operators] Please enable Forward
49 matches
Mail list logo