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
anything like this currently, or honestly ever could.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
