W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: HTTP Unprompted Authentication

From: Ben Schwartz <bemasc@google.com>
Date: Wed, 19 Oct 2022 09:59:21 -0400
Message-ID: <CAHbrMsCTqiuqNHbuLJTY5E0u2obOYcVNcPUwt4Eg6=YggWLcZw@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Oct 18, 2022 at 5:49 PM David Schinazi <dschinazi.ietf@gmail.com>

> Hi Ben,
> I don't think confidential HTTP resources are a solved problem. The
> unguessable path approach you describe is similar to a shared secret (à la
> symmetric cryptography) but there is no equivalent for
> asymmetric cryptography.

I would appreciate some explanation of why asymmetric cryptography is
helpful in Unprompted Authentication.

Normally, asymmetric signatures are used to prevent the verifier, or an
onlooker, from impersonating the signer.  However, that consideration does
not apply here, because the exchange is already confidential (thanks to
"https") between the verifier (the origin) and the signer (the client) so
there are no (untrusted) onlookers, and there is only one potential
verifier (the origin itself).

Another possible threat would be an onlooker on the "bootstrap" path. e.g.
the email exchange in which the client learned about this confidential
resource.  However, such an onlooker has already learned about the
existence of the resource, thus defeating the confidentiality protection,
so it must be excluded from the threat model.

If client keys are reused across multiple origins, this could justify the
use of asymmetric cryptography, but that would be a bad idea anyway for
linkability reasons.

If I were trying to make the strongest case for Unprompted Authentication,
it would be that "unguessable" URLs tend to leak in browser history,
whereas other authorization credentials are more easily protected.  This
could justify the new HTTP header, but it doesn't imply any use of
asymmetric crypto.

> While I think your draft is interesting and worth discussing, I think the
> technology overlap isn't big enough to warrant discussing the two drafts
> together - they're separate proposals with different goals.

They're definitely separate, and use unrelated technology.  I do think the
ultimate goals overlap considerably.


Received on Wednesday, 19 October 2022 13:59:45 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC