On 29 Oct 2013, at 19:46, Jesse Thompson <[email protected]> wrote:
> > > On 10/29/2013 12:59 PM, Dave Cridland wrote: >> On Tue, Oct 29, 2013 at 5:46 PM, Peter Saint-Andre <[email protected] >> <mailto:[email protected]>> 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
smime.p7s
Description: S/MIME cryptographic signature
