Re: HTTP Unprompted Authentication

OK, that explains some things about the design.  It's definitely not what I
expected, and I'm interested to hear more about how this fits together.

Given that every multi-CDN shard is (1) authoritative for the origin, (2)
observes an arbitrary subset of the secret resources, and (3) is capable of
impersonating any user to the origin backend, I'm not sure I quite get the
threat model.  But maybe if each "shard" is a separate origin, and they
need to share user authentication keys across origins...

On Wed, Oct 19, 2022 at 6:08 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

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