jdev - 2019-10-03

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?

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"

I think "policies" means something different here

"(e.g., a policy requiring TLS)" doesn't help 😀

I mean if the user intentation was to use direct TLS wouldn't that qualify as a policy?

at least in email everybody uses TCP/587 STARTTLS now and refuses to connect if TLS isn't negotiated successfully

TCP/467 is only for legacy reasons

you wish

Oh submission/-s, not imap/-s. But it'll probably be 443 soon anyways 🙁

it is if you try to shoehorn every last god damn thing into a browser

no, for real, everyone's singing high praise for jmap

which is json+https, like everything else

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.

Hi Daniel, I'm ready to test conversation <-> Gajim FT

asterix, ok

can you add me on daniel@gultsch.de

tom: you missed https://tools.ietf.org/html/rfc8314 which brings smtps over TCP port 465 back

huh

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

what happens when we stop using TLS like we did with SSL?

Basically STARTLS is the deprecated way

What do you mean?

with cleartext init when TLS becomes deprecated we just deny STARTTLS and put in a STARTNGE (next generation encryption)

Is STARTTLS any less secure than TLS?

Quic ? :)

It's complicated, but basically yes

does anybody even use that besides google?

Because it allows non encrypted and that's not acceptable today

like the failure of webp

Yes, everyone

moparisthebest no, the server and or client can refuse further coms unless STARTLS is negotiated

technically TLS is cleartext until KEX happens

In practice though, it's impossible to try TLS and accidentally communicate in clear text

I'm skeptical of QUIC and the security of stream ciphers

Not true with STARTLS

You better tell someone because like 50% of the web is already using it

yeah

and people adopted TLS session ticketing and got compromised too

Curl, chrome, Firefox, cloudflare, Google, soon everyone else

and then people adopted the complex HTTP/2 protocol too early before extensive in-practice testing could be finished and become vulnerable to RCEs

I think it'll be great for xmpp too, no more stream management, just proper roaming

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

and I would like to see some practical examples of STARTTLS being less secure than TLS

>‎moparisthebest‎: You better tell someone because like 50% of the web is already using it Not on my routers and DPI points

There are plenty of examples of ISPs stripping starttls and bad clients etc still connecting

I also don't know what you mean by stream ciphers, as I understand it quic *essentially* uses TLS 1.3

Let me ask a different question instead, what advantage does Starttls have over direct TLS? I can't think of one

if a client program connects in cleartext despite being configured not to that's a defect with the program not the protocol.

yes, look at archived mailing lists from server operators of why we switched to a STARTTLS system in the first place?

*.

To save ports by allowing encrypted and unencrypted on the same port right?

And now everyone agrees there should never be unencrypted, so again, what's the point?

Stream ciphers are ciphers that can tolerate a dropped packets or other parts of the stream and not have to renegotiate

this makes stopping stream tampering more difficult

take AES for example

normally you'd operate it in GCM mode

not CTR mode

we do this because there are all kinds side channels that open up when using it in stream mode

like for example if you happen you run out of entropy, you expose your private key

Has there been major problems with DTLS? Surely it's similar

I'm not a cryptographer but I trust the IETF to get it right

compound this with that popularity of virtualization, embedded computers, and Intel's backdoored hardware RNG blackbox

it would be the first time a standards body had a malicious agenda https://en.wikipedia.org/wiki/Dual_EC_DRBG

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

that was NIST not IETF and many people knew from the start it was backdoored