[Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Ruslan N. Marchenko me at ruff.mobi
Mon Feb 13 19:26:48 UTC 2017



On 13.02.2017 19:58, Travis Burtrum wrote:
> Boy am I glad you missed the last call deadline by a day so I don't have
> to address your concerns. :)
>
> On 02/12/2017 11:03 AM, Sam Whited wrote:
>> A minor nitpick: The requirements section isn't really requirements,
>> it's the actual main content of the spec.
> Someone mentioned that before but didn't respond when I asked where they
> should be, such as how it should be re-arranged.
>
>> In the introduction and security concerns there are claims that this
>> spec provides "perhaps increased security and privacy over using
>> STARTTLS". These claims use both passive language ("perhaps"), and I
>> don't think are actually true (it's only slightly less trivial to
>> detect that not-HTTPS is most likely being transmitted, and lots of
>> corporate firewalls do this). Since these are weak statements to begin
>> with, I'd like to see them taken out in case they mislead users. I
>> don't think it provides any value to the specification to include
>> claims like this anyways, true or false.
>>
>> It would be nice if these statements could be removed before the
>> council votes; apologies for being late to the party in bringing this
>> up again.
> It's worded in a passive way because it depends on the choices you make
> with regard to the spec.  If you send ALPN, well then that's not any
> additional privacy over STARTTLS, you are still announcing to the middle
> boxes you intend to talk XMPP over this TLS connection.  As discussed
> before, if you enforce STARTTLS regardless of stripping, well then
> direct TLS that has no plain fallback doesn't give you extra security.
>
> Also it was previously noted in the absence of DNSSEC only allowing
> xmpp-* records through instead of xmpps-* had a similar effect to
> STARTTLS stripping, which is true, but also SRV records have a TTL that
> a client could keep across different networks, so that could also remove
> this possibility for a man in the middle with control over DNS right?
> Again up to the server administrator how high they want to set their TTLs.
>
> Lastly I could not disagree more with "it's only slightly less trivial
> to detect that not-HTTPS is most likely being transmitted, and lots of
> corporate firewalls do this", unless you mean detecting with ALPN, I
> think analyzing traffic patterns of the stream underlying TLS to pick
> apart XMPP vs HTTP vs anything else would be insanely difficult, surely
> it'd make most HTTP sites fail too.  I doubt any corporations implement

When corporate is paranoid for security they just deploy transparent 
mitm/bumping proxy with root CA installed on all corporate workstations 
and sniffing the traffic applying all the corporate security/dlp rules.
So anything what does not speak HTTP pretending to be HTTPS will just 
die there. So security here will be just in the sense "all or nothing" - 
either you pass through (non-paranoid) or not (paranoid).
> anything like this currently, or honestly ever could.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>



More information about the Standards mailing list