[Operators] Fwd: [jdev] TLS Everywhere
stpeter at stpeter.im
Tue Oct 29 18:59:02 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 10/29/13 12:46 PM, Jesse Thompson wrote:
> On 10/29/2013 12:59 PM, Dave Cridland wrote:
>> On Tue, Oct 29, 2013 at 5:46 PM, Peter Saint-Andre
>> <stpeter at stpeter.im <mailto:stpeter at stpeter.im>> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> On 10/29/13 11:40 AM, Jesse Thompson wrote:
>>> On 10/28/2013 2:52 PM, Peter Saint-Andre wrote:
>>>> On 10/28/13 1:41 PM, Jesse Thompson wrote:
>>>>> Are there more details? Specifically, does "hop-by-hop
>>>>> encryption using SSL/TLS" require strong association
>>>>> between a domain name and an XML stream as described in
>>>> We, as a community, need to figure out what we can do.
>>>> Realistically, I think we need to prefer authenticated
>>>> encryption via PKI, POSH, or DNSSEC/DANE and fall back to
>>>> opportunistic encryption via TLS + dialback.
>>> So, the presumption is that servers which aren't capable of at
>>> least TLS+dialback will be cut off?
>> Now, this is a proposal, not an ultimatum. We, as a community,
>> need to come to a decision about whether this is a reasonable
>> course of action. However, I do think we owe it to the users of
>> our services to provide a higher level of security.
>> Also, if phrased right, we could say that the Good Servers talk
>> with each other securely, but they may also have exceptions to
>> deal with legacy services which do not yet perform full
> If being an exception is the past of least resistance - for both
> the operator needing to change as well as the operator who is
> compelled to enforce the change - then how do you prevent everyone
> from being an exception?
> I like the proposal to "provide user or administrative interfaces
> showing [TLS details]" because that has the potential to cause
> end-users to bug their service operators to implement better
> security, which will cause service operators to bug server
> developers to implement new security features.
> That seems like something that can start phasing in right away.
> Is it reasonable to expect the popular XMPP clients to begin
> showing TLS information to end-users earlier in the proposed
Many already do.
And the new "IM Observatory" is helping:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Operators