Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Matthew Wild
On Tue, 27 Sept 2022 at 13:22, Dave Cridland 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 >

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Dave Cridland
On Tue, 27 Sept 2022 at 12:59, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 12:31, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > >> > - I seem to remember that HT-* derives a lot of its replay protection

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Matthew Wild
On Tue, 27 Sept 2022 at 12:31, Dave Cridland wrote: > On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: >> > - I seem to remember that HT-* derives a lot of its replay protection from >> > the channel binding, so we may want to have

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Dave Cridland
On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > >> > >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > > I'd not considered web clients - can they not obtain the server >

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Matthew Wild
On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: >> >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > I'd not considered web clients - can they not obtain the server certificate > at all, even these days? I'm not aware of any method

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Dave Cridland
On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > >> Before committing to this, some observations: >> >> - HT-*-NONE is needed for cases where there's no TLS at all. These are >> rare, but there's legitimate cases where this is a sensible

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Matthew Wild
On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > Before committing to this, some observations: > > - HT-*-NONE is needed for cases where there's no TLS at all. These are > rare, but there's legitimate cases where this is a sensible choice. > - Channel bindings can be used in cases where TLS

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Dave Cridland
On Tue, 27 Sept 2022 at 08:39, Daniel Gultsch wrote: > But I agree that it should be optional; I already said this in the ISR > thread: There are plenty of scenarios where channel binding is not an > option. > Before committing to this, some observations: - HT-*-NONE is needed for cases where

Re: [Standards] Channel binding and token authentication

2022-09-27 Thread Daniel Gultsch
On Mon, Sep 26, 2022 at 7:28 PM Matthew Wild wrote: > > The current specs say that channel binding is a mandatory requirement. > However this excludes web clients from using the mechanisms, even > though they would be one of the key client groups to benefit from > being able to exchange

Re: [Standards] Channel binding and token authentication

2022-09-26 Thread Travis Burtrum
Sep 26, 2022 7:42:48 AM Kevin Smith : > -- Original Message -- > From: "Matthew Wild" > To: "XMPP Standards" > Sent: 26/09/2022 18:24:37 > Subject: [Standards] Channel binding and token authentication > >> Does anyone have objections to proceeding with the definition of one >> or more

Re: [Standards] Channel binding and token authentication

2022-09-26 Thread Kevin Smith
-- Original Message -- From: "Matthew Wild" To: "XMPP Standards" Sent: 26/09/2022 18:24:37 Subject: [Standards] Channel binding and token authentication Does anyone have objections to proceeding with the definition of one or more HT-*-NONE mechanisms for token authentication? Seems