https://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-see-other-host it's unclear to me, should I attempt direct TLS if the original intention was to connect using direct TLS?
Wojtekhas joined
sonny
direct TLS not being part of RFC 6120 I would say no but it says "the initiating entity MUST apply the same policies it would have applied to the original connection"
MattJ
I think "policies" means something different here
sonny
"(e.g., a policy requiring TLS)" doesn't help 😀
sonny
I mean if the user intentation was to use direct TLS wouldn't that qualify as a policy?
ajhas left
bhaveshsguptahas left
bhaveshsguptahas joined
wurstsalathas left
wurstsalathas joined
bhaveshsguptahas left
bhaveshsguptahas joined
jrmuhas left
jrmuhas joined
jrmuhas left
jrmuhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
tom
at least in email everybody uses TCP/587 STARTTLS now and refuses to connect if TLS isn't negotiated successfully
tom
TCP/467 is only for legacy reasons
bhaveshsguptahas joined
jonas’
you wish
Zash
Oh submission/-s, not imap/-s. But it'll probably be 443 soon anyways 🙁
tom
it is if you try to shoehorn every last god damn thing into a browser
Zash
no, for real, everyone's singing high praise for jmap
Zash
which is json+https, like everything else
Kev
I'm not opposed to a j-xmpp for the last mile, I think it makes quite a lot of sense. Despite jabs about xmpp over json.
jrmuhas left
jrmuhas joined
jrmuhas left
jrmuhas joined
Wojtekhas left
Wojtekhas joined
jrmuhas left
jrmuhas joined
debaclehas joined
lovetoxhas joined
marc0shas left
marc0shas joined
qqhas joined
jrmuhas left
jrmuhas joined
qqhas left
asterixhas joined
asterix
Hi Daniel, I'm ready to test conversation <-> Gajim FT
Daniel
asterix, ok
Daniel
can you add me on daniel@gultsch.de
jrmuhas left
jrmuhas joined
jrmuhas left
jrmuhas joined
Wojtekhas left
Wojtekhas joined
jrmuhas left
rionhas left
rionhas joined
jrmuhas joined
Wojtekhas left
bhaveshsguptahas left
bhaveshsguptahas joined
Wojtekhas joined
lovetoxhas left
jrmuhas left
jrmuhas joined
jrmuhas left
jrmuhas joined
jrmuhas left
jrmuhas joined
Egor Leontevhas joined
Egor Leontevhas left
asterixhas left
skyfarhas joined
jrmuhas left
moparisthebest
tom: you missed https://tools.ietf.org/html/rfc8314 which brings smtps over TCP port 465 back
tom
huh
moparisthebest
Also IMAP/pop3/managesieve can go over any 443 or TLS port with their registered alpn extensions https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
tom
what happens when we stop using TLS like we did with SSL?
moparisthebest
Basically STARTLS is the deprecated way
moparisthebest
What do you mean?
tom
with cleartext init when TLS becomes deprecated we just deny STARTTLS and put in a STARTNGE (next generation encryption)
tom
Is STARTTLS any less secure than TLS?
moparisthebest
Quic ? :)
moparisthebest
It's complicated, but basically yes
tom
does anybody even use that besides google?
moparisthebest
Because it allows non encrypted and that's not acceptable today
tom
like the failure of webp
moparisthebest
Yes, everyone
tom
moparisthebest no, the server and or client can refuse further coms unless STARTLS is negotiated
wurstsalathas left
tom
technically TLS is cleartext until KEX happens
moparisthebest
In practice though, it's impossible to try TLS and accidentally communicate in clear text
tom
I'm skeptical of QUIC and the security of stream ciphers
moparisthebest
Not true with STARTLS
moparisthebest
You better tell someone because like 50% of the web is already using it
tom
yeah
tom
and people adopted TLS session ticketing and got compromised too
and then people adopted the complex HTTP/2 protocol too early before extensive in-practice testing could be finished and become vulnerable to RCEs
moparisthebest
I think it'll be great for xmpp too, no more stream management, just proper roaming
tom
I'm not saying it's not worh researching, I'm saying that calling STARTTLS or TCP/TLS 'deprecated' in favor of stream ciphers and UDP based transports is premature
tom
and I would like to see some practical examples of STARTTLS being less secure than TLS
tom
>moparisthebest: You better tell someone because like 50% of the web is already using it
Not on my routers and DPI points
moparisthebest
There are plenty of examples of ISPs stripping starttls and bad clients etc still connecting
moparisthebest
I also don't know what you mean by stream ciphers, as I understand it quic *essentially* uses TLS 1.3
moparisthebest
Let me ask a different question instead, what advantage does Starttls have over direct TLS? I can't think of one
tom
if a client program connects in cleartext despite being configured not to that's a defect with the program not the protocol.
tom
yes, look at archived mailing lists from server operators of why we switched to a STARTTLS system in the first place?
tom
*.
moparisthebest
To save ports by allowing encrypted and unencrypted on the same port right?
moparisthebest
And now everyone agrees there should never be unencrypted, so again, what's the point?
tom
Stream ciphers are ciphers that can tolerate a dropped packets or other parts of the stream and not have to renegotiate
tom
this makes stopping stream tampering more difficult
tom
take AES for example
tom
normally you'd operate it in GCM mode
tom
not CTR mode
tom
we do this because there are all kinds side channels that open up when using it in stream mode
tom
like for example if you happen you run out of entropy, you expose your private key
moparisthebest
Has there been major problems with DTLS? Surely it's similar
moparisthebest
I'm not a cryptographer but I trust the IETF to get it right
tom
compound this with that popularity of virtualization, embedded computers, and Intel's backdoored hardware RNG blackbox
tom
it would be the first time a standards body had a malicious agenda https://en.wikipedia.org/wiki/Dual_EC_DRBG
tom
not saying it's impossible to have an unbreakable sidechannel free stream cipher, just saying it's really hard to get right and historically it's been done wrong a lot of times
debaclehas left
moparisthebest
that was NIST not IETF and many people knew from the start it was backdoored