Hi Mike, > On 22. Nov 2019, at 16:00, Mike Jones > <[email protected]> wrote: > > TLS on Web Servers is nearly ubiquitous now and works great. Trying to use > mutual TLS on many platforms results in a nearly intractable user experience, > where the end-users are asked to install certificates into certificate > stores. Success rates for those UXs are very low. > > And it's even worse than that. If you use multiple browsers, you'll have to > get the person to install the client certificates into multiple certificate > stores. For instance, on Windows, Edge, Firefox, and Chrome all use > different certificate stores. > > Server-side TLS works because end-users don't have to do anything difficult > to use it. That can't be said for client-side TLS.
That’s true for the user experience in a browser. That’s why we currently need an alternative for exactly this client type. It’s completely different for mobile apps and server-side web applications since mTLS does not have any impact on the user experience at all. Instead, the developer just needs to drop the key pair/cert into the HTTP stack and is done with both client authentication and sender constrained tokens. best regards, Torsten. > > -- Mike > > -----Original Message----- > From: OAuth <[email protected]> On Behalf Of Torsten Lodderstedt > Sent: Thursday, November 21, 2019 11:54 PM > To: Justin Richer <[email protected]> > Cc: oauth <[email protected]> > Subject: [EXTERNAL] Re: [OAUTH-WG] New Version Notification for > draft-fett-oauth-dpop-03.txt > > > >> On 22. Nov 2019, at 15:24, Justin Richer <[email protected]> wrote: >> >> I’m going to +1 Dick and Annabelle’s question about the scope here. That was >> the one major thing that struck me during the DPoP discussions in Singapore >> yesterday: we don’t seem to agree on what DPoP is for. Some (including the >> authors, it seems) see it as a quick point-solution to a specific use case. >> Others see it as a general PoP mechanism. >> >> If it’s the former, then it should be explicitly tied to one specific set of >> things. If it’s the latter, then it needs to be expanded. > > as a co-author of the DPoP draft I state again what I said yesterday: DPoP is > a mechanism for sender-constraining access tokens sent from SPAs only. The > threat to be prevented is token replay. > > The general mechanism for sender constrained access token should be TLS-based > as recommended by the Security BCP (see > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3.2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&sdata=tvqS9JnASGHWeVZnxm0x6Rr7sSCaMX5Hd7ImpyoN%2BqE%3D&reserved=0).. > > Why: that’s the easiest way from a client developer's perspective. > > Application level signatures, on the other hand, are inherently more fragile > as illustrated by the OAuth 1 experience. They also require additional effort > (and state) on the server side to implement replay detection. > > As kind of an entertaining read I added two posts/threads from 2010, when > this WG discussed whether TLS/SSL should be the primary OAuth 2.0 security > mechanism. > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FcrVvDNtbdN0E0ccmk5fLdNS66v0&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&sdata=EYJcPaUIPorvsaZtHTcRhztyoc7aT5HvoISpCe%2FJi2w%3D&reserved=0 > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Foauth%2F%3Fgbt%3D1%26index%3Dxvlxuly1DjQiZgWZpHwgj7q2k0g&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&sdata=EaoRe%2BF2guKYB%2B9exMnl3oeyAEmS3%2FvQXV2BcXgYyOg%3D&reserved=0 > > The decision to go with TLS only was, in my opinion, one of the key success > factors that made OAuth 2 so incredibly successful. > > To re-state: From my perspective, DPoP is intended to be used by SPA > developers only for token replay detection (or better put to provide RSs with > the pre-requisites to do so). > > Why? Because we unfortunately currently lack a TLS-based mechanism for > sender-constraining. > > Building it on asymmetrical crypto only makes it easier to implement and to > handle than methods based on shared secrets. > > I also think we must look for alternative methods to enable TLS-based methods > in the browser. > > >> >> I’ll repeat what I said at the mic line: My take is that we should >> explicitly narrow down DPoP so that it does exactly one thing and solves one >> narrow use case. And for a general solution? Let’s move that discussion into >> the next major revision of the protocol where we’ll have a bit more running >> room to figure things out. >> >> — Justin >> >>> On Nov 22, 2019, at 3:13 PM, Dick Hardt <[email protected]> wrote: >>> >>> >>> >>> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <[email protected]> >>> wrote: >>> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <[email protected]> >>> wrote: >>>> There are key distribution challenges with that if you are doing >>>> validation at the RS, but validation at the RS using either approach means >>>> you’ve lost protection against replay by the RS. This brings us back to a >>>> core question: what threats are in scope for DPoP, and in what contexts? >>> >>> Agreed, but validation at the RS is premature optimisation in many cases. >>> And if you do need protection against that the client can even append a >>> confirmation key as a caveat and retrospectively upgrade a bearer token to >>> a pop token. They can even do transfer of ownership by creating copies of >>> the original token bound to other certificates/public keys. >>> >>> While validation at the RS may be an optimization in many cases, it is >>> still a requirement for deployments. >>> >>> I echo Annabelle's last question: what threats are in scope (and out of >>> scope) for DPoP? >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&sdata=hOjycnvqIbTATvSdKNl1%2BwZMcNZcip99Yozys9%2FXy8w%3D&reserved=0 >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfa8cfb57efe34b5dfafa08d76f21234d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100060427907236&sdata=hOjycnvqIbTATvSdKNl1%2BwZMcNZcip99Yozys9%2FXy8w%3D&reserved=0 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
