[Operators] Fwd: [jdev] TLS Everywhere

Olle E. Johansson oej at edvina.net
Tue Oct 29 19:28:34 UTC 2013

On 29 Oct 2013, at 19:46, Jesse Thompson <jesse.thompson at doit.wisc.edu> 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:
>>    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?

On the topic of user-interfaces:

- How does a a server that fails to setup a s2s session indicate the failure back to a client?
- Does the protocol support an error message saying "certificate failure" or "TLS not available"?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2374 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131029/db4e5496/attachment.bin>

More information about the Operators mailing list