Re: [Privacy-pass] [Ohai] Fwd: New Version Notification for draft-schwartz-ohai-consistency-doublecheck-03.txt

Hi Ben,

I think that this worth doing.  I have tons of nits[1], but nothing that warrants any notice at this stage.

The only high-level comment I'd offer is that this draft concerns itself overly much with things outside of its scope, sometimes using normative language for things that I would prefer it be silent on.  For instance, you require - with a "MUST NOT" - that if the proxy offers DNS service it disable EDNS client subnet.  That's overreach in my view, and not the only example of that sort of thing.  Duplicating HTTP requirements is similarly overreach in a different way.

I would prefer that this follow the key consistency draft into the privacy pass working group, just so that tranche of work all happens in the same place.

Cheers,
Martin

[1] For some reason, a missing comma after "e.g." irks me more than it should.  And empty sections (7>7.1>7.11 with no text in between).  But all of that stuff can be fixed easily.

On Thu, Oct 20, 2022, at 07:14, Ben Schwartz wrote:
> Hello OHAI and PRIVACYPASS,
>
> This revision of the DoubleCheck draft makes extensive changes based on 
> feedback from the last session and subsequent discussions:
>
> * The draft no longer has a normative dependency on 
> draft-schwartz-masque-access-descriptions or OHTTP.
> * The draft no longer recommends CONNECT-UDP over CONNECT.
> * The "MUST" requirement to provide and use a transport proxy has been 
> reduced to SHOULD, with explanation about the risks if one is not used.
> * The introduction has been expanded to describe how this procedure 
> might be useful for both OHTTP and Privacy Pass.
> * The example (Section 5) has been adjusted to make use of 
> draft-pauly-ohai-svcb-config.
> * The draft introduces its own capitalized terminology for the three 
> parties, similar to OHTTP and Privacy Pass.
>
> The protocol itself has not changed since the previous revision.
>
> I would like to present this revision at IETF 115 if possible.
>
> Good topics for feedback:
>
> * Is this bending HTTP Cache-Control semantics too far?
> * Is there any way to solve the Thundering Herd problem (Section 6.2) 
> using only HTTP caching directives?
> * Which working group would be best to discuss this?
>
> --Ben Schwartz
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Wed, Oct 19, 2022 at 3:58 PM
> Subject: New Version Notification for 
> draft-schwartz-ohai-consistency-doublecheck-03.txt
> To: Benjamin M. Schwartz <bemasc@google.com>
>
>
>
> A new version of I-D, draft-schwartz-ohai-consistency-doublecheck-03.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
>
> Name:           draft-schwartz-ohai-consistency-doublecheck
> Revision:       03
> Title:          Key Consistency by Double-Checking via a Semi-Trusted 
> Proxy
> Document date:  2022-10-19
> Group:          Individual Submission
> Pages:          15
> URL:            
> https://www.ietf.org/archive/id/draft-schwartz-ohai-consistency-doublecheck-03.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-schwartz-ohai-consistency-doublecheck/
> Html:           https://www.ietf.org/archive/id/draft-schwartzAs the 
> draft is more general-ohai-consistency-doublecheck-03.html 
> <https://www.ietf.org/archive/id/draft-schwartz-ohai-consistency-doublecheck-03.html>
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-schwartz-ohai-consistency-doublecheck
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-schwartz-ohai-consistency-doublecheck-03
>
> Abstract:
>    Several recent IETF privacy protocols require clients to acquire
>    bootstrap information for a service in a way that guarantees both
>    authenticity and consistency, e.g., encrypting to the same key as
>    many other users.  This specification defines a procedure for
>    transferring arbitrary HTTP resources in a manner that provides these
>    guarantees.  The procedure relies on access to a semi-trusted HTTP
>    proxy, under the same security assumptions as an Oblivious HTTP
>    Relay.
>
>
>
>
> The IETF Secretariat
>
>
> -- 
> Ohai mailing list
> Ohai@ietf.org
> https://www.ietf.org/mailman/listinfo/ohai
>
> Attachments:
> * smime.p7s