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

Re: HTTP Unprompted Authentication

From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 19 Oct 2022 15:08:34 -0700
Message-ID: <CAPDSy+4ZXvgwT6eQteqEUacuQ5fXRoq_DDyebrz5T-3SxzG3oQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
You summarized the landscape pretty well - the main goal of asymmetric
cryptography here is the case where the origin is sharded (e.g., the
multi-CDN use case) and you don't want one of the shards to be able to
impersonate a user to another shard. An example scenario is running
on-ramps to Tor distributed amongst volunteers. This allows you to share
the credentials of authorized users while preventing impersonation. I also
agree with you that paths tend to leak not only in browser history, but in
server access logs, etc.


On Wed, Oct 19, 2022 at 6:59 AM Ben Schwartz <bemasc@google.com> wrote:

> On Tue, Oct 18, 2022 at 5:49 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>> 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 22:08:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC