Re: [Ohai] New Version Notification for draft-pauly-ohai-svcb-config-01.txt

[Ben Schwartz <[e-mail]>]

Thanks Tommy!  Unsurprisingly, I like this direction.

I do think this version has a remaining "consistency" problem in the "dns"
scheme: the "dohpath" is not consistency-protected.  A hostile server could
issue distinct "dohpath" values to every user, defeating the linkability
protections provided by key consistency.  For this reason, I think the DoH
URI template and the KeyConfig need to be treated atomically, and protected
by a shared consistency mechanism.  (I posted drafts last month covering
such a combined configuration [1] and consistency mechanism [2].)

I'm slightly confused by Section 3.2.  Is this describing "standard DoH
over OHTTP", or is this related to the earlier "Oblivious DoH" draft?  If
the first (which I prefer), perhaps this could be adjusted to clarify that
there is nothing new being defined here, and the outer Content-Type is
still "message/ohttp-req".

Finally, I wonder how you think clients (e.g. browsers) should treat the
"oblivious" flag in general HTTP usage.  Should browsers respect it and
switch to OHTTP for those domains, if they are able?  Ignore it entirely?
Use it only when making requests that don't carry cookies?

Relatedly, are you sure that the origin is the proper scope for a flag like
this?  It seems to me that an HTTP origin might offer some resources or
services that are suitable for access over OHTTP, and some that are not.
Perhaps the origin scope is appropriate for origin-identified services, but
not for URL-identified services?  Or are we asking providers to partition
all OHTTP services onto a separate origin, which raises some privacy
concerns of its own?

--Ben

[1]
https://datatracker.ietf.org/doc/html/draft-schwartz-masque-access-descriptions-00
[2]
https://datatracker.ietf.org/doc/html/draft-schwartz-ohai-consistency-doublecheck-00


On Wed, May 25, 2022 at 12:14 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

> Hello OHAI,
>
> This revision of the draft for discovering oblivious targets with SVCB
> records goes in the simplified direction discussed on list and at IETF 113.
>
> Specifically, this defines:
> - A boolean “oblivious” SVCB parameter to provide a hint that a server
> supports being an oblivious target
> - A well-known URI to host the oblivious target keys
>
> There may also need to be other attributes defined, such as paths on the
> target, but I’d like to hear if people prefer this direction.
>
> Thanks,
> Tommy
>
> > On May 25, 2022, at 8:53 AM, [e-mail] wrote:
> >
> >
> > A new version of I-D, draft-pauly-ohai-svcb-config-01.txt
> > has been successfully submitted by Tommy Pauly and posted to the
> > IETF repository.
> >
> > Name:         draft-pauly-ohai-svcb-config
> > Revision:     01
> > Title:                Discovery of Oblivious Services via Service
> Binding Records
> > Document date:        2022-05-25
> > Group:                Individual Submission
> > Pages:                9
> > URL:
> https://www.ietf.org/archive/id/draft-pauly-ohai-svcb-config-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-pauly-ohai-svcb-config/
> > Html:
> https://www.ietf.org/archive/id/draft-pauly-ohai-svcb-config-01.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pauly-ohai-svcb-config
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-pauly-ohai-svcb-config-01
> >
> > Abstract:
> >   This document defines a parameter that can be included in SVCB and
> >   HTTPS DNS resource records to denote that a service is accessible as
> >   an Oblivious HTTP target, as well as a mechanism to look up oblivious
> >   key configurations using a well-known URI.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
>
> --
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai
>