Re: [Ohttp] Benjamin Kaduk's No Objection on charter-ietf-ohttp-00-02: (with COMMENT)

[Martin Thomson <[e-mail]>]

Thanks Ben,

I think that the biggest piece here is making it clear that we aren't inventing new crypto.  We don't need to, and we aren't, so the charter probably shouldn't allow that interpretation.  In line with that, I've reworded the "key configuration" stuff as well.

I'm also removing "data submission" (I am aware of concrete plans, but that text is too vague to be useful) and we have enough items already.

I hope that https://github.com/unicorn-wg/ohttp-charter/pull/8 does the job.

On Thu, Aug 26, 2021, at 07:26, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> charter-ietf-ohttp-00-02: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-ohttp/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The new introductory paragraphs are really good; thank you for the
> rewrite!
> 
> I don't think that just using "encryption scheme" as a shorthand for
> "not new cryptographic primitives" is very effective; we should probably
> say something else about "encryption <something-else>"s that are
> approved by the CFRG/etc.
> 
>     However, if the proxy and server collude, then neither of these
>     privacy properties hold.
> 
> I'd consider saying something about how both client and server have to
> have trust in the proxy to behave properly (though exactly what they're
> trusting the proxy to (not) do is slightly different for client and
> server).  It's less clear whether it's useful to say something here
> about how a colluding client and proxy can attack the server.
> 
>     Examples include DNS queries, data or telemetry submission, [...]
> 
> "data submission" seems pretty vague/broad in a way that "telemetry data
> submission" does not.
> 
>     the relationship between client, server, and cooperating proxy is
>     typically configured out-of-band.
> 
> Is "is typically" really appropriate given that OHTTP doesn't really exist
> yet?
> 
>     The working group will define any encryption scheme necessary and
>     supporting data formats for carrying encapsulated requests and
>     responses, plus any key configuration that might be needed to use the
>     protocol.
> 
> Is "key configuration" meant to encompass (abstract) data structures,
> data formats, and/or protocols that convey those data objects?
> 
> 
> 
> -- 
> Ohttp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohttp
>