On Tue, 27 Sept 2022 at 13:22, Dave Cridland <[email protected]> wrote: > All of which I broadly agree with to various degrees, however that's not the > attack here - the attack is that a passive observer can replay TLS 1.3 Early > Data, and if a client developer (fairly sensibly) chooses to send a SASL > exchange there, that might get to the point of an authenticated connection. > It's one the attacker cannot control, mind - confidentiality has still been > assured - but if a client developer were to use TLS Early Data to send both > the SASL exchange *and* a message or something, then that might be a problem.
The pending updates to SASL2 forbid Early Data. The pending token auth spec allows it if negotiated, but also adds a per-token counter to protect against replays. This works independently of SASL mechanism or channel binding. Channel binding (e.g. with tls-server-end-point) is not adequate protection against this replay attack, and was not intended as such protection, to my knowledge. > In other protocols also using SASL, though, it might be a worse problem - in > principle some uses of Submission (ie, SMTP for sending mails) might be > susceptible here, and there could be some other issues even on broadly > readonly protocols like IMAP. Yes. Correctly specified and implemented, we don't have these problems (with or without channel binding). > In any case, given the focus for HT-* is 0-RTT startup, it makes a lot of > sense to try to ensure it has some protection for replay - saying "Well, if > you want to save on round-trips, you can use HT-*-NONE, but then you'll need > to disable TLS Early Data and spend an additional RTT there" doesn't seem > like an ideal situation. > > Meanwhile in the HTTP world, verified TLS and a session cookie is *very* > susceptible to replay attacks based on TLS 1.3 Early Data, and it's often > blocked as a result (for example, Cloudflare reject it for anything except > "plain" GET requests, and Go doesn't even implement it, and ... ). Given it > weakens forward secrecy for the Early Data, too, there's not just replay > issues to consider anyway. > > Anyway, something to worry over when looking at HT-*-NONE - and to be > explicit, my knowledge here is getting very sketchy, so I don't even know if > HT-* with (say) TLS Exporter channel bindings is any better. If the primary practical value of channel binding is only to work around a problem in something that nobody currently implements - a problem which also has simpler and more correct workarounds available - I rest my case :) Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
