- From: Ben Schwartz <bemasc@google.com>
- Date: Wed, 19 Oct 2022 09:59:21 -0400
- To: David Schinazi <dschinazi.ietf@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAHbrMsCTqiuqNHbuLJTY5E0u2obOYcVNcPUwt4Eg6=YggWLcZw@mail.gmail.com>
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. >
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 19 October 2022 13:59:45 UTC