jdev - 2021-06-16

  1. stpeter

    Random TLS question ... do we know if anyone using 0-RTT mode with TLS 1.3 in XMPP?

  2. stpeter

    (Context: I'm updating RFC 7525 with my co-authors and we'll likely not recommend 0-RTT mode unless there's a specification for using it in a given application protocol, as there is for http/2.)

  3. Zash

    I don't know anything of the sort.

  4. stpeter

    0-RTT mode is ... interesting and needs to be handled with care.

  5. Zash

    Opening stream header ... might be safe to use with it?

  6. moparisthebest

    I suppose your advice applies even more for QUIC 0-rtt ?

  7. moparisthebest

    is it just no forward secrecy and replay attacks or something else?

  8. stpeter

    Mostly replay attacks, AIUI.

  9. moparisthebest

    those are dangerous in HTTP land because the replayed-thing could be "send $X to bob"

  10. moparisthebest

    but xmpp stream headers seem... ok ?

  11. Zash

    As long as you don't attempt SASL pipelining

  12. moparisthebest


  13. stpeter

    Hmm yeah. Thus the recommendation to have a spec in place. Don't just wing it!

  14. moparisthebest

    I mean, even if you did, they could repeatedly log in as you and not be able to proceed further? still probably ok

  15. jonas’

    SASL pipelining would still be safe with SCRAM, right?

  16. flow

    stpeter, xep397 § 6. and the accompaning sasl-ht I-D discuss using 0-rtt data

  17. moparisthebest

    jonas’, I think if it's safe with SCRAM it's also safe without SCRAM ?

  18. flow

    so basically, if you do it right™, then instant stream resumption would be a nice use case for 0-rtt data

  19. moparisthebest

    attackers can't decrypt it, only replay it

  20. flow

    you just™ have to make sure that you leak nothing else into the 0-rtt data

  21. stpeter

    flow: thanks for the pointer

  22. jonas’

    moparisthebest, PLAIN has no nonce, so if you pipeline all the things the attacker could replay whatever happens in the zeroth round trip I guess?

  23. moparisthebest

    how do those differ, I mean, what happens if PLAIN is in early-data vs SASL stuff

  24. moparisthebest

    I think it's the same result

  25. Zash

    SCRAM has >0 roundtrips

  26. jonas’

    SCRAM has a nonce and a forced round-trip. you cannot do a full authentication with SCRAM with zero round trips. so if you were to replay, you would hit a brick there with SCRAM, while you could probably authenticate with a PLAIN replay.

  27. Zash

    If someone does a pipelined PLAIN, bind, and Something, then maybe you could replay that.

  28. Zash

    All this gets more relevant with {SASL,BIND,*}2

  29. moparisthebest

    there's a limit to the amount of early-data that can be sent anyway, and I think the server sets it

  30. flow

    moparisthebest, is that limit part of the protocol or a implementation specific thing?

  31. stpeter

    I believe that 0-RTT is used mainly in HTTP, where the client isn't (typically) authenticating with the server. The fact that XMPP uses TLS+SASL introduces different considerations.

  32. stpeter

    (I'm also checking with people who know about the use of TLS in protocols like IMAP and SMTP.)

  33. moparisthebest

    flow, https://www.rfc-editor.org/rfc/rfc8446#section-4.6.1 max_early_data_size

  34. moparisthebest

    but also, it helps with resumption, which matters a lot for TCP+TLS but not really at all for QUIC because your QUIC connections can survive roaming across endpoints etc

  35. Zash

    Is resumption used with XMPP at all?

  36. Zash

    Is TLS* resumption used with XMPP at all?

  37. flow

    moparisthebest, any idea about the typical value of this paramater?

  38. moparisthebest

    absolutely no idea, can't find anything with a quick search either

  39. moparisthebest

    it's a uint32 though if that helps :D

  40. moparisthebest

    couldn't you just in general say "don't send bind in early-data" for clients ?

  41. Kev

    stpeter: We’re not currently doing 0RTT, but we’re very interested in this and want to do so at some point.

  42. stpeter

    Kev: good to know, thanks for the input! We should think about the best ways to do this.

  43. Kev

    For X2X this would be particularly interesting, and for reduced-RTT client auth.

  44. stpeter

    Indeed. Mobile is likely a key use case.