Re: HTTP Unprompted Authentication

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.

David

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.
>
>>