[Standards] Channel binding and token authentication

Matthew Wild mwild1 at gmail.com
Tue Sep 27 13:05:46 UTC 2022


On Tue, 27 Sept 2022 at 13:22, Dave Cridland <dave at cridland.net> 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


More information about the Standards mailing list