[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:
> 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:
>>> 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 


More information about the Operators mailing list