[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:
>>
>> -----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?
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"?
/O
-------------- 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