[Operators] Fwd: [jdev] TLS Everywhere

Peter Saint-Andre stpeter at stpeter.im
Tue Oct 29 18:59:02 UTC 2013


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

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJScAV2AAoJEOoGpJErxa2pJmoP/2Qitd4pQahnKvOm5cBgU1al
uVDsMLdR5wWXSM2rHsR6g2o9cJojVxMRyRJKvy3insQeqaHta9jWzkFEKD5/PSWp
GOKhw3SKFfT3GqfVkUdQnMxZkCtOglDP22tOSBPByQlIhYQsOWYhapX/EaUqzGjh
LxCKE5thwXvqduHrSuOIcr8MfoBo/07KPr0rpHqF0YerbUrXhFAWOvNFDVKrZVlr
wKtRh4ODjmAAoqdBvIoTflol431u0xPeBIL2DTmgdYqW2dgOlRQEpNI7ywrVzCzD
LNdCK3d9v9W2dbOC5NgmpNgRb0omm4rMihGBLTOK5yVq2nrd/iCZkxRFUSi1sGvN
epe+T1TF/9UwSnzPFkWiCBrk0/rfro/I04xKWIZlGvJ0rh451x22AgMz8LQuDkAk
aShM+9FiqvMAPlZCGXVURn5WuK+titchrdzgbat/DTVmEp5n+IX3FRcQT+llqca1
PiiGV7X4S26FwgYcFllp2b6Y9p5It9UrMMiOxbE4RUvmJD9Ia01DwI1P57xCqKIW
33MWogYqlhsGaYMpwjkq3QAPxRy51uvlx8CVQmKlm7h0v1ItxyvFaye7fXZ7t9NR
Lf25Pe63eQLtFkwFS7QsaQfyXxNS/E4ofXxZeHkE2OZsq7ie4undexsUtEkjsBAw
lYrTSs6P3f9jlQVJnwvh
=F1wX
-----END PGP SIGNATURE-----


More information about the Operators mailing list