Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-group-privacypass-consistency-mirror in state "Candidate for WG Adoption"

[Martin Thomson <[e-mail]>]

I'm not 100% on the design here.

As much as I like BHTTP, I don't see any value in it being used here.  However, that conclusion depends on subsequent points to some extent.  See issue 25.

It's not entirely clear to me, but it seems like the client doesn't fetch the original resource.  I see a big fat "otherwise..." attached to the text about fetching that resource in Section 4, which implies that the mirror fetch is the only fetch.  I would prefer to see a direct fetch, perhaps via some form of intermediary that can hide IP address, with a confirmation via the mirror.  This is essential to ensure that the resource is *correct* as well as consistent.  See issue 27.

As an optimization, if the confirmation request does not need to provide the client with content at all.  The request can be made using the HEAD method and a Want-Content-Digest field, so that the response can carry a hash rather than a complete copy of the content.

Alternatively, the mirror resource could only provide hashes as the entirety of the representation that it provides, avoiding HEAD and Digest fields entirely, but it seems like there is some value in being able to inspect the inconsistent value.

I raised a few other issues as well.  I think this needs a little bit more polish.  If the WG wants to do this (rather than what Richard might be suggesting) then this is a fine starting point though.

Cheers,
Martin

On Fri, Dec 1, 2023, at 08:07, IETF Secretariat wrote:
> The PRIVACYPASS WG has placed draft-group-privacypass-consistency-mirror in
> state Candidate for WG Adoption (entered by Benjamin Schwartz)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-group-privacypass-consistency-mirror/
>
>
> -- 
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass