jdev - 2021-06-16

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

(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.)

I don't know anything of the sort.

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

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

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

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

Mostly replay attacks, AIUI.

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

but xmpp stream headers seem... ok ?

As long as you don't attempt SASL pipelining

yes

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

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

SASL pipelining would still be safe with SCRAM, right?

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

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

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

attackers can't decrypt it, only replay it

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

flow: thanks for the pointer

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?

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

I think it's the same result

SCRAM has >0 roundtrips

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.

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

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

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

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

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.

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

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

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

Is TLS* resumption used with XMPP at all? ✏

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

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

it's a uint32 though if that helps :D

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

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

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

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

Indeed. Mobile is likely a key use case.