[Operators] Fwd: [jdev] TLS Everywhere

Jesse Thompson jesse.thompson at doit.wisc.edu
Wed Oct 30 13:13:13 UTC 2013


On 10/29/2013 1:59 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>>>>>> draft-ietf-xmpp-dna-04?
>>>>>
>>>>> 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?
>>>
>>> Yes.
>>>
>>> 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
>>> security.
>>
>> 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
>> timeline?
>
> Many already do.
>
> And the new "IM Observatory" is helping:
>
> https://twitter.com/zeank/status/395106608310525952

That's really cool (I like the rif on SSL Labs).  Are clients pulling 
results from xmpp.net, or doing their own analysis?

In the same vein, I wasn't aware of this before 
http://www.process-one.net/en/imtrends/  I figured it wouldn't hurt to 
submit a request for enhancement 
https://support.process-one.net/browse/TRNDS-21

Jesse


More information about the Operators mailing list