[Operators] Gmail federation

[Marco Cirillo]

Il 11/01/2013 14:14, Dave Cridland ha scritto:
> On Fri, Jan 11, 2013 at 1:05 PM, Marco Cirillo <maranda at lightwitch.org> wrote:
>> I just pointed out that it's like this from 2006 which is when it was
>> implemented, perhaps it can't be "suprising" also stated it's rather an
>> inconveniency and that it's not compliant with the current RFC which
>> requires TLS support on s2s streams (which can hardly be interpreted as "we
>> do support but not deploy it").
> No, it is mandatory to implement, but not to deploy, as Philip says.
> Google are breaking no MUSTs here.
>
> In Google's case, they have stated very clearly, and very often, that
> TLS authentication is essentially somewhere between very difficult and
> impossible for them to deploy, and (quite rightly) they've argued that
> without this there's little worth in mere unauthenticated encryption.
> This might explain the push for things like DANE and POSH.
>
> I'm afraid this means that any server operating a policy of mandatory
> TLS will fail to interop with Google's domains for now as a result -
> but anyone who operates a server with a mandatory policy of TLS, but
> doesn't also do TLS authentication *and* full revocation checks is
> likely to be missing some important implications, at the very least.
>
> The most productive thing people could do here is review the current
> POSH draft and look at ways of making mass-hosted XMPP and PKIX work
> together more effectively, rather than attacking the symptom.
>
> Dave.
Dave,
I sort of remember Google's reasons for not "enabling" encryption for 
s2s streams as they were discussed several times (in this same ML iirc) 
as you mentioned and find some reasonable, some less.

But still I have to insist there's a problem RFC wise, not dealing with 
xmpp from a while I didn't exactly remember certain parts of the new 
xmpp-core so while reading the ML discussion I repopped 'em up for 
reference, admittedly to avoid getting mislead, and say "It's not 
compliant" I should have read a bit further, but still the following 
remains:

5.2. is not subject to interpretations "REQUIRE(/D)" equals to a MUST, 
and re-reading the whole doc section a bit throughly the use of the 
*Support* term in that contest is even incoherent as 5.4.1. right after 
cites << If the receiving entity *supports* TLS, the stream features 
MUST include an advertisement for support of STARTTLS negotiation, i.e., 
a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' 
namespace. >> that means a server would be allowed not only to just not 
*offer* TLS but also not implement it, contradicting 5.2.

Perhaps maybe the RFC there could benefit a few passages (this is 
probably a bit too OT but I'll try to cut it here).

I'd like to also point out, expecially how STARTTLS is handled xmpp 
wise, that you can't know what gets implemented and what doesn't 
explicitly as long as you don't have the software, it's code or the 
implemented thing reaches "the wire" or worse, getting into a world of 
pointless assumptions.