jdev - 2019-10-03


  1. sonny

    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?

  2. 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"

  3. MattJ

    I think "policies" means something different here

  4. sonny

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

  5. sonny

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

  6. tom

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

  7. tom

    TCP/467 is only for legacy reasons

  8. jonas’

    you wish

  9. Zash

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

  10. tom

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

  11. Zash

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

  12. Zash

    which is json+https, like everything else

  13. 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.

  14. asterix

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

  15. Daniel

    asterix, ok

  16. Daniel

    can you add me on daniel@gultsch.de

  17. moparisthebest

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

  18. tom

    huh

  19. 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

  20. tom

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

  21. moparisthebest

    Basically STARTLS is the deprecated way

  22. moparisthebest

    What do you mean?

  23. tom

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

  24. tom

    Is STARTTLS any less secure than TLS?

  25. moparisthebest

    Quic ? :)

  26. moparisthebest

    It's complicated, but basically yes

  27. tom

    does anybody even use that besides google?

  28. moparisthebest

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

  29. tom

    like the failure of webp

  30. moparisthebest

    Yes, everyone

  31. tom

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

  32. tom

    technically TLS is cleartext until KEX happens

  33. moparisthebest

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

  34. tom

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

  35. moparisthebest

    Not true with STARTLS

  36. moparisthebest

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

  37. tom

    yeah

  38. tom

    and people adopted TLS session ticketing and got compromised too

  39. moparisthebest

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

  40. tom

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

  41. moparisthebest

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

  42. 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

  43. tom

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

  44. tom

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

  45. moparisthebest

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

  46. moparisthebest

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

  47. moparisthebest

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

  48. tom

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

  49. tom

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

  50. tom

    *.

  51. moparisthebest

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

  52. moparisthebest

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

  53. tom

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

  54. tom

    this makes stopping stream tampering more difficult

  55. tom

    take AES for example

  56. tom

    normally you'd operate it in GCM mode

  57. tom

    not CTR mode

  58. tom

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

  59. tom

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

  60. moparisthebest

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

  61. moparisthebest

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

  62. tom

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

  63. tom

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

  64. 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

  65. moparisthebest

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