DNS media type

[tfpauly]

Ralf Weber pointed out the DNS media type we mention is application/dns-message. We likely need a specific type defined for doing DNS-over-OHTTP (slightly different from the previous ODoH type) that would be the outer type, or have the application/oblivious-dns-message be defined to allow this use in OHTTP (although that would be ambiguous).

[bemasc]

I think the outer type should be message/ohttp-req. I see no reason for the client to reveal to the relay whether a particular request is DoH or some other usage of HTTP.

[chris-wood]

For what it's worth, I agree with Ben here.

[tireddy2]

Agree with Ben.

[tfpauly]

The current text is talking about the inner request type.

For HTTPS services, it says:

For the "https" scheme, which uses the HTTPS RR type instead of SVCB, the presence of the "oblivious" parameter means that the target being described is an Oblivious HTTP service that is accessible using the default "message/bhttp" media type.

For DNS services, it says:

For the "dns" scheme, as defined in DNS-SVCB, the presence of the "oblivious" parameter means that the DNS server being described is an Oblivious DNS over HTTP (DoH) service. The default media type expected for use in Oblivious HTTP to DNS resolvers is "application/dns-message".

This isn't talking about the outer type, but rather than the content of the message is application/dns-message.

The question then is what the outer type is. The main OHTTP document says it shouldn't be ohttp-req

Future specifications may repurpose the encapsulation mechanism described in this document. This requires that the specification define a new media type.

Which I don't love, because it does tell relays and everyone what kind of content you're sending... but that's what it says at the moment.

[chris-wood]

Ah! If this is the inner content type, then I've no objections. This content type is never revealed to the relay, it's only only used to ensure safe separation across protocols and content agreement between client and gateway. OHTTP doesn't require the outer content type to change -- is must always be message/ohttp-req or whatever. It only requires the content type of used in the key schedule to be unique for the inner content type.

So all in all there's no issue with choosing a new type, which seems to be suggested with the last comment?

[bemasc]

@chris-wood I don't think you're saying the same thing as @tfpauly ...

For the "dns" scheme, as defined in DNS-SVCB, the presence of the "oblivious" parameter means that the DNS server being described is an Oblivious DNS over HTTP (DoH) service.

I think this might be source of the problem.

We've been using the term "Oblivious DoH' as a shorthand for this protocol, but I think the protocol should actually be "DoH using Oblivious HTTP". In that arrangement, this is a perfectly ordinary HTTP transaction, using Oblivious HTTP as usual, with an outer type of message/ohttp-req and an inner type of message/bhttp, which in turn contains a GET or POST request, the latter with an application/dns-message Content-Type.

In this formulation, the "oblivious" parameter is not used directly by DNS-SVCB. The SVCB-DNS spec says:

All keys specified for use with the HTTPS record are also permissible, and apply to the resulting HTTP connection.

This is where oblivious would come into play, modifying the HTTP connection used for DoH. So instead, this draft could say

For the "dns" scheme, if an HTTP ALPN ID is present, the "oblivious" parameter modifies the HTTP connection that underlies each DoH request. Clients that support Oblivious HTTP SHOULD disable any other use of this record or ensure that any other use provides privacy equivalent to Oblivious HTTP. Clients also SHOULD disable any DNS features that would allow linking of independent DNS requests, such as DNS Cookies.

---

Regarding the guidance in OHTTP:

Future specifications may repurpose the encapsulation mechanism described in this document.

Yes, I think this would apply to non-HTTP uses of the Oblivious Relay and Gateway ... but DoH is not a non-HTTP use case.

[chris-wood]

The OHTTP guidance is as follows: the outer content type never changes, and the key schedule content type must match that of the inner content type. I think Ben's interpretation of what's actually happening here (DoH using Oblivious HTTP) is correct.

[bemasc]

Unfortunately, I now understand that Section 4.6 of OHTTP is contributing to the confusion. Instead of "DoH using Oblivious HTTP", it imagines something like "Oblivious DNS using an OHTTP Relay" in which:

• The outer Content-Type is a new type, not message/ohttp-req.
• The inner "info string" is application/dns-message (request|response).
• There is no DoH URI template or dohpath.

This approach has nothing whatsoever to do with RFC 8484 DoH. It's a completely new DNS transport that happens to reuse some parts of the OHTTP system, relying on an Oblivious Gateway that changes its behavior based on the outer Content-Type.

This approach is coherent, but it requires a custom DNS-aware Gateway, prevents the use of multiple DNS endpoints via a single Gateway, and leaks the distinction between DNS and HTTP requests to the Relay. On the other hand, it avoids complications about ensuring the consistency of the dohpath, and reduces message overhead.

I think draft-ohai-svcb-config hasn't quite figured out which of these two proposals it's recommending. It should probably pick one, and draft-ietf-ohai-ohttp should be updated to match it.

[tfpauly]

I'm going to lean towards just using BHTTP as an extra layer of wrapping, and let it be standard OHTTP. That should be simplest. I'll propose this in the meeting.

[tfpauly]

115 meeting agreed that this should just be standard OHTTP Gateway (with BHTTP) + standard DoH server.