Subject: [DNSOP] unsolicited HTTPSSVC responses

From: Eric Orth <[email-masked]>
Date: Tue, 26 May 2020 15:43:27 -0400

One of my colleagues recently brought up the idea of suggesting recursives
add additional HTTPSSVC records into responses for A/AAAA queries as a way
to make HTTPSSVC more available for cases where a stub is hesitant to make
additional queries out of concern for bad behavior from bad middleboxes (a
frequent concern for Chrome when not using DoH).  My initial impression is
that it's not a reasonable idea, but I wanted to bring it here to DNSOP in
case anybody has further ideas to make it workable.  So any relevant
thoughts or concerns from anybody here?

The obvious problems I could think of (all basically along the theme of it
not being ideal when the stub might not even care about HTTPSSVC):

   - Performance implications if the recursive has to retrieve HTTPSSVC or
   follow alias chains.  Maybe not as bad if only done opportunistically when
   the recursive happens to already have everything in cache.
   - Polluting DNS for non-browsers.  Maybe not as bad if SVCB instead of
   HTTPSSVC, but this would likely only be of use for web browsers which are
   obviously not the only queryers of A/AAAA.
   - Could lead to lots of unnecessary truncation, especially for large
   records containing ESNI data.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2020 23:05:34 +0000

> thoughts or concerns from anybody here?

proposals exist going way back to add AAAA to additional data for answers of 
type A, and to add A to additional data for answers of type AAAA. this is not 
different from adding A and AAAA to additional data for answers of MX and SRV, 
which already happens. your proposal fits the same mold, which is that the 
spec neither requires nor prohibits it. however, the client API likely does 
not have a way to benefit from the additional data in a stub response. see 
getdnsapi.net for a representative example of something that can only tell you 
answers to the question you asked, even if it knows more, and won't keep the 
response in state just in case your next question could also be answered by 
it. getdnsapi has a return_both_v4_and_v6 extension but would need another API 
change to support HTTPSSVC.

for SMTP senders to benefit from the additional AAAA/A data in MX answers, 
they have to call a lower level API such as res_nsend() and then walk through 
the response to see what they actually got, in hopes of not needing to make a 
second query for addresses (or a second and third, if V6 and V4 are 
available.)

so, this way lies madness, and the solution we see most often is a host-level 
cache of DNS results. the old INN (usenet net news) server had one of these, 
and all modern browsers have one. many of us simply run a validating iterative 
caching recursive resolver on our hosts, since it's not much code by modern 
standards. but in all such cases we don't have a good way to retrieve more 
than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not 
well defined and is broadly unimplemented. various other multiple-questions 
proposals have been made but nothing gets traction.

>    follow alias chains.  Maybe not as bad if only done opportunistically
> when the recursive happens to already have everything in cache.

your self-criticisms are all valid in my opinion. however, i think it would be 
fine to recommend in the HTTPSSVC draft that the necessary subsidiary data 
like AAAA or A or SVCB all be sent, both in authoritative and non-
authoritative responses, when the qtype is HTTPSSVC and the responder knows 
the additional data (that is, it should not make extra queries to find it just 
for additional data reasons.) this will push UDP/53 DNS into either TCP/53 DNS 
(via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or even 
TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ).

long answers are our future. if this data is going to be nec'y to make the 
primary answer useful, then pre-seeding it is a net good. some day our 
descendants will break the tyranny of MTU 1500, and thank us for any prework 
that brought the data their apps needed closer and with fewer round trips.

-- 
Paul

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 26 May 2020 19:56:30 -0400

On Tue, May 26, 2020 at 7:06 PM Paul Vixie <[email-masked]> wrote:
...

> however, i think it would be
> authoritative responses, when the qtype is HTTPSSVC

FWIW, this is pretty much what the HTTPSSVC draft currently says.

and the responder knows
> for additional data reasons.)

The current text does not have this caveat: it recommends that the
recursive perform those extra queries before replying, because they will
otherwise have to be performed by the client at higher cost.  However, it
also says "recursive resolvers MAY ... produce a reply that omits some of
the associated RRSets ... when responding before fully chasing dependencies
would improve performance", so a compliant recursive resolver could
certainly implement the behavior you're describing.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 May 2020 00:00:19 +0000

On Tuesday, 26 May 2020 23:56:30 UTC Ben Schwartz wrote:
> otherwise have to be performed by the client at higher cost.

i think that's overly prescriptive. the client may already have the data in 
private cache from its prior work, or it may be striping its DNS queries 
across several full resolvers and therefore able to get the data faster if you 
don't provide it than if you take the time to fetch it before you answer.

> However, it

nice. that's all the rope i'd ask for.

-- 
Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 May 2020 00:18:14 +0000

On May 26, 2020, at 12:43 PM, Eric Orth <ericorth=[email-masked]> wrote:
> One of my colleagues recently brought up the idea of suggesting recursives add additional HTTPSSVC records into responses for A/AAAA queries

Add where in the response? In the Answer section or in the Additional section? The semantics and usefulness are wildly different for those two.

--Paul Hoffman

---

From: Petr Špaček <[email-masked]>
Date: Wed, 27 May 2020 08:33:57 +0200

> proposals have been made but nothing gets traction.

I would much rather spent time on
https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03

That would bring benefit to broader set of clients and has advantage that server does not send back data nobody asked for (thus wasting resources on unnecessary work).

I feel that nowadays web browsers have better communication with OS vendors/stub resolvers (Android and Chrome come to mind). Can we stub resolvers on board, pretty please?

-- 
Petr Špaček  @  CZ.NIC

---

From: Ray Bellis <[email-masked]>
Date: Wed, 27 May 2020 09:30:31 +0100

On 27/05/2020 07:33, Petr Špaček wrote:

> That would bring benefit to broader set of clients and has advantage
> that server does not send back data nobody asked for (thus wasting
> resources on unnecessary work).

I'd be very happy to revive that work if there's interest.

Ray

---

From: Eric Orth <[email-masked]>
Date: Wed, 27 May 2020 12:07:06 -0400

On Tue, May 26, 2020 at 7:05 PM Paul Vixie <[email-masked]> wrote:

> not have a way to benefit from the additional data in a stub response.

Not a blocking concern for Chrome because in many cases it uses a built-in
stub resolver that could easily read anything it wants out of the
responses.  But it certainly limits whether or not we would try to convince
recursive operators to do this if it is likely to only be of benefit to
Chrome.  Also exacerbates all the concerns around things not being ideal if
the stub is not going to use the HTTPSSVC if even less stubs are able to
use it.

> see

---

From: Eric Orth <[email-masked]>
Date: Wed, 27 May 2020 12:15:01 -0400

On Tue, May 26, 2020 at 8:18 PM Paul Hoffman <[email-masked]> wrote:

> > One of my colleagues recently brought up the idea of suggesting
> recursives add additional HTTPSSVC records into responses for A/AAAA queries
>
> Add where in the response? In the Answer section or in the Additional
> section? The semantics and usefulness are wildly different for those two.
>

I assume Additional, but I honestly don't have much personal perspective on
the implications of which section is used since from the perspective of the
stub code I deal with, it's not an issue to look for HTTPSSVC records in
either section.

---

From: Eric Orth <[email-masked]>
Date: Wed, 27 May 2020 12:40:25 -0400

On Wed, May 27, 2020 at 2:34 AM Petr Špaček <[email-masked]> wrote:

> That would bring benefit to broader set of clients and has advantage that
> server does not send back data nobody asked for (thus wasting resources on
> unnecessary work).
>

Maybe a better solution, but considering that the issue I'm dealing with is
when the stub is unwilling to send additional queries or queries for new
types out of concerns of middlebox ossificiation (especially from older
home routers) on additional queries or unknown query types, does anybody
have any data to show that the multiple qtype EDNS option won't cause
similar issues?

But in other cases without as much ossifciation concern, especially when
using DoH, I'm supportive of any effort to allow querying multiple types in
the same request.  Would significantly help with some of the security
concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by
identifying and blocking the packets just for the HTTPSSVC records.  If
A/AAAA/HTTPSSVC are all in the same request/response, you can't block any
of it without blocking all of it.  My one concern of that specific proposal
is that if the client doesn't know that the server will respond for the
additional queries, it still has to make separate queries for all three,
leading to lots of redundant responses when the additional types are
handled.

>
> I feel that nowadays web browsers have better communication with OS
> vendors/stub resolvers (Android and Chrome come to mind). Can we stub
> resolvers on board, pretty please?
>
> --
> Petr Špaček  @  CZ.NIC
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 27 May 2020 22:48:35 +0100

On 27/05/2020 17:40, Eric Orth wrote:

> Maybe a better solution, but considering that the issue I'm dealing with
> is when the stub is unwilling to send additional queries or queries for
> new types out of concerns of middlebox ossificiation (especially from
> older home routers) on additional queries or unknown query types, does
> anybody have any data to show that the multiple qtype EDNS option won't
> cause similar issues?
> 
> using DoH, I'm supportive of any effort to allow querying multiple types
> in the same request.  Would significantly help with some of the security
> A/AAAA/HTTPSSVC are all in the same request/response, you can't block
> any of it without blocking all of it.  My one concern of that specific
> proposal is that if the client doesn't know that the server will respond
> for the additional queries, it still has to make separate queries for
> all three, leading to lots of redundant responses when the additional
> types are handled.

In traditional DNS, stub resolvers only talk to a limited set of
upstream resolvers, and they could learn (and cache) information about
their behaviours, in the same way that recursive servers do for
authoritative servers.

You only need to launch one "multi QTYPE" query at a server to learn
whether subsequent queries to that server can take advantage of that
feature.

Ray

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 May 2020 00:54:36 +0100

> section? The semantics and usefulness are wildly different for those

We learned from DNAME that a lot of DNS software gets very upset if there
are unexpected records in the answer section. If you want to add
additional records they have to go in the additional section.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Easterly 3 to 5, veering southeasterly 5 or 6 in southwest
Fastnet. Slight or moderate. Fair. Good.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 28 May 2020 10:00:05 +0200

Ray and other DNS operations folks,

> I'd be very happy to revive that work if there's interest.

As I have mentioned several times on microphone, I think this draft has 
huge potential, potentially cutting the number of queries handled by 
recursive resolvers almost in half - since they could ask for A and AAAA 
records in a single query.

I wonder what work is left other than implementation?

Possibly it makes sense to describe client how stub or forwarding 
resolvers may want to probe their full-service resolvers? I expect that 
normal behavior would be:

1. Send a query with the Multi-QTYPE option and see if the resolver 
supports it.
2. If it does to send single queries for address lookups instead of 
parallel AAAA/A queries.
3. Fallback to parallel AAAA/A queries as soon as they get a response 
that does not support Multiple-QTYPE.

Similar description for recursive-to-authoritative might be helpful, 
since resolvers cache information about authoritative servers. I guess 
we could expect resolvers to ask for DNSKEY and NS together when it 
makes sense, for example.

Of course, these use cases can be left as an exercise to the implementer.

--
Shane

---

From: Petr Špaček <[email-masked]>
Date: Thu, 28 May 2020 10:17:55 +0200

On 28. 05. 20 10:00, Shane Kerr wrote:
> As I have mentioned several times on microphone, I think this draft has huge potential, potentially cutting the number of queries handled by recursive resolvers almost in half - since they could ask for A and AAAA records in a single query.
> 

Most importantly we are missing buy-in (or more precisely _any communication_) with stub resolvers which are actually used by applications. If anyone from Android, iOS, Microsoft, glibc would like to comment here it would be ideal.

Personally I:
a) Very much like idea of this draft
b) At the same time I'm against making this RFC until we have end-to-end implementation.

If we do not have implementations on all ends this draft will simply end up as yet another item on my "list of dnsop failures" with drafts published but never implemented, and that's huge waste of everybody's time.

> 
> Possibly it makes sense to describe client how stub or forwarding resolvers may want to probe their full-service resolvers? I expect that normal behavior would be:
> 
> 1. Send a query with the Multi-QTYPE option and see if the resolver supports it.
> 2. If it does to send single queries for address lookups instead of parallel AAAA/A queries.
> 3. Fallback to parallel AAAA/A queries as soon as they get a response that does not support Multiple-QTYPE.
> 
> Similar description for recursive-to-authoritative might be helpful, since resolvers cache information about authoritative servers. I guess we could expect resolvers to ask for DNSKEY and NS together when it makes sense, for example.

Yes, certainly... but ideally this should be done in concert with stub resolver developers so they can tell us what they need from the protocol. Most famously glibc resolver might not have sufficient state to cache this information, or ... I don't know.

Petr Špaček  @  CZ.NIC

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 28 May 2020 18:22:25 +0200

Hello.

On 5/28/20 10:00 AM, Shane Kerr wrote:
> As I have mentioned several times on microphone, I think this draft
> has huge potential, potentially cutting the number of queries handled
> by recursive resolvers almost in half - since they could ask for A and
> AAAA records in a single query. 

I'm not sure if it would be a net benefit if we consider the added
complexity (like the few unpleasant corner cases), the need to implement
on both sides, and other ways that are available.  Is saving the number
of IP-layer packets the only significant motivation?

For resolver-to-auth case I do suspect some potential.  Plain UDP will
probably still stay popular there for some time.  Though I'm afraid this
might _sometimes_ push the answer sizes too large to fit into one packet
(in signed zones), which in my eyes slightly reduces attractiveness of
the technique, now that we know that UDP over 1.5 kB is no good.

For non-auth cases, you typically communicate with just one upstream
resolver (or very few), so if the number of packets is a concern, I'd go
for a long-lived TCP or TLS connection (there's e.g. privacy motivation,
too).  That's all standardized already, and it naturally avoids those
extra corner cases.  Sure, it's probably possible to improve
significantly on session timers and resuming, performance, usage of
Nagle's algorithm, etc. but ATM to me that feels a more worthwhile
investment than any of the multi-answer proposals.  One advantage is
that many of the TCP/TLS improvements can be deployed one-sidedly with
some effect but multi-QTYPEs can't.

--Vladimir

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 May 2020 13:47:36 -0400

On 28 May 2020, at 12:22, Vladimír Čunát <[email-masked]> wrote:

> For resolver-to-auth case I do suspect some potential.  [...]

This is a tangent, and not directly related to the topic of packing extra records into an answer section.

This general separation of stub-to-resolver and resolver-to-auth use cases seems like it's coming up more often. Another recent example is the question of discovery of available transports (DoT, DoH, etc) for stub-to-resolver is being examined as a separate problem from the same question for resolver-to-auth, which I think is also reasonable.

Architecturally, today, we treat those use cases (and others like forwarder-to-resolver, or forwarder-to-forwarder) as all using the same protocol in all the senses of that phrase.

Perhaps it's time to look at whether it would be useful to draw some boundaries across what is currently one diagram describing how people look stuff up. It seems to me that there are useful distinctions we could make in response behaviour, for example, depending on whether it's auth-to-resolver or resolver-to-stub. Access control, transport security and privacy and amplification potential also seem like they might be considered differently in different parts of the system.

We already have some flags that only mean anything for particular use-cases, like AD that is meaningless in a response from auth to resolver. Maybe we could consider an evolution of the architecture to make it more clear that we can imagine different optimisations being applied to different parts of it.

Just a thought.

Joe

---

From: Eric Orth <[email-masked]>
Date: Thu, 28 May 2020 15:21:32 -0400

I lead engineering for the stub resolver built into Chrome browser, so
while not an OS-level stub, maybe still prominent enough to count for the
"any communication" requested above.

My biggest concern with an approach like this is ossification from
middleboxes (especially some old home routers) that may not be ideally
engineered for the modern web.  Chrome has seen significant issues in the
past with such middleboxes creating pain (super slow responses mostly) for
a small number of our users on sending unusual queries or an increased
amount of queries.  As such, we're generally afraid of sending out anything
other than basic and rate-limited requests when it comes to Classic DNS.
Attempting new things and falling back to conservative behavior on an issue
is not necessarily a reasonable approach because the middlebox pain is not
always limited to the individual queries.  In some cases, probing or
experimenting with resolver capabilities can cause user pain for all
subsequent queries for a period of time on the order of minutes.

Since this specific multi-query proposal encodes it in EDNS, it might be
more reasonable.  I don't have any actual data to back this up, but I would
guess that unknown EDNS options are less likely to cause issues than
completely unknown queries.  So it might be safe enough to at least do
super cautious experimentation around it.

Note that none of these ossification issues are really a concern with DoH
(or DoT) where we can be reasonably sure we're talking to a modern
non-ossified resolver.  The usefulness of combining queries is a little
reduced since DoT and DoH often use connection sharing for multiple
requests anyway.  But there's still some potential value.  In ECH (ESNI)
discussions, it has come up a few times that an attacker could try to force
a downgrade from ECH by identifying and blocking the larger packets
containing HTTPSSVC responses that contain ECH keys but not address
resolves.  Much safer if A/AAAA and HTTPSSVC can be in the same
query/response to force an attacker to block everything or nothing.

Additional possible issues with this multi-query proposal:
*By combining A and AAAA, you might lose nice abilities to try to speed
things up using Happy Eyeballs v2 style algorithms to immediately start
using addresses as they come in, before all addresses are received.  Not
currently a huge issue for Chrome DNS because we don't currently support
Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that
improvement.
*The current proposal seems to give the resolver a lot of leeway to only
sometimes include the additional results and includes a TODO note that
maybe there should be a way for clients to mark qtypes as mandatory.  I
don't think the client would get as much use out of multiple qtypes unless
it had reasonable confidence that it would at least usually get all the
responses.  Otherwise, the client is often going to have to make multiple
requests in parallel anyway to ensure it can get all the responses
reasonably quickly in parallel.  Then again, if it's something like
requesting an extra qtype that we would be afraid to send in Classic DNS
anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more
value of just adding in the additional qtype and using the response
opportunistically when received.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 29 May 2020 08:47:39 +0200

>From my resolver implementer view, these variants actually _are_ different protocols which merely share the same wire format and port number.

Differences between mentioned protocol manifest itself any time we encounter a network which silently redirects all traffic on port 53 to local resolver. Recursive resolution attempts in such networks fails horribly because the protocols are actually different and fields mean different things.

Having said that ...

> We already have some flags that only mean anything for particular use-cases, like AD that is meaningless in a response from auth to resolver. Maybe we could consider an evolution of the architectur…

I very much agree, we need to clean up this historical mess!

Clear split between stub/forwarding/recursive would help a lot.

-- 
Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Fri, 29 May 2020 09:06:07 +0200

On 28. 05. 20 21:21, Eric Orth wrote:
> I lead engineering for the stub resolver built into Chrome browser, so while not an OS-level stub, maybe still prominent enough to count for the "any communication" requested above.
> 
> My biggest concern with an approach like this is ossification from middleboxes (especially some old home routers) that may not be ideally engineered for the modern web.  Chrome has seen significant issues in the past with such middleboxes creating pain (super slow responses mostly) for a small number of our users on sending unusual queries or an increased amount of queries.  As such, we're generally afraid of sending out anything other than basic and rate-limited requests when it comes to Classic DNS.  Attempting new things and falling back to conservative behavior on an issue is not necessarily a reasonable approach because the middlebox pain is not always limited to the individual queries.  In some cases, probing or experimenting with resolver capabilities can cause user pain for all subsequent queries for a period of time on the order of minutes.
> 
> Since this specific multi-query proposal encodes it in EDNS, it might be more reasonable.  I don't have any actual data to back this up, but I would guess that unknown EDNS options are less likely to cause issues than completely unknown queries.  So it might be safe enough to at least do super cautious experimentation around it.

I would say it depends on sheer luck:
EDNS handling is specified in RFC 2671 from 1999, unknown type handling is in RFC 3597 from 2003. Both should work in 2020. If they don't because resolver vendors does not care.

> 
> Note that none of these ossification issues are really a concern with DoH (or DoT) where we can be reasonably sure we're talking to a modern non-ossified resolver.

Sorry but I think you have unrealistic hopes, probably caused by largely nonexistent auto-disovery of DoH/DoT servers.

AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ!box router - mainstream in Germany and countries around) are adding support for DoT and possibly also DoH. Personally I do not see any reason why their resolver available over DoT/DoH should work any better than their unencrypted DNS resolver, which is (at least not in case of AVM) not famous for standards-compliance or performance. Of course vendors are going to reuse whatever they had before, so additional TLS+HTTP layers will just add new bugs on top of whatever bugs they had before.

In other words, whole anti-ossification argument seems to hold at the moment only because of missing auto-discovery protocol for encrypted transports. Once we have auto-discovery all the problems will bounce back. Sorry for my grim predictions!

> The usefulness of combining queries is a little reduced since DoT and DoH often use connection sharing for multiple requests anyway.  But there's still some potential value.  In ECH (ESNI) discussions, it has come up a few times that an attacker could try to force a downgrade from ECH by identifying and blocking the larger packets containing HTTPSSVC responses that contain ECH keys but not address resolves.  Much safer if A/AAAA and HTTPSSVC can be in the same query/response to force an attacker to block everything or nothing.

Hmm, shouldn't it be detected at TLS layer? It seems to me that only explotable problem would be if client interpreted connection timeout or TLS errors as missing ESNI RR, which does not sound like a good idea to me.

> *By combining A and AAAA, you might lose nice abilities to try to speed things up using Happy Eyeballs v2 style algorithms to immediately start using addresses as they come in, before all addresses are received.  Not currently a huge issue for Chrome DNS because we don't currently support Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that improvement.

Interesting... Do you have measurements which suggest that A/AAAA answers have different timing properties? I would expect it mostly depends on whatever is in cache, and if multi-query takes off we can expect both to be present in cache with the same TTL.

> *The current proposal seems to give the resolver a lot of leeway to only sometimes include the additional results and includes a TODO note that maybe there should be a way for clients to mark qtypes as mandatory.  I don't think the client would get as much use out of multiple qtypes unless it had reasonable confidence that it would at least usually get all the responses.  Otherwise, the client is often going to have to make multiple requests in parallel anyway to ensure it can get all the responses reasonably quickly in parallel.  Then again, if it's something like requesting an extra qtype that we would be afraid to send in Classic DNS anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more value of just adding in the additional qtype and using the response opportunistically when received.

I agree - making it mandatory seems like reasonable approch (within certain limits, e.g. answer size etc.).

Petr Špaček  @  CZ.NIC

> 
> On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello.
>

---

From: Eric Orth <[email-masked]>
Date: Fri, 29 May 2020 14:02:25 -0400

On Fri, May 29, 2020 at 3:06 AM Petr Špaček <[email-masked]> wrote:

> EDNS handling is specified in RFC 2671 from 1999, unknown type handling is
> in RFC 3597 from 2003. Both should work in 2020. If they don't because
> resolver vendors does not care.
>

Right.  I'm sure we'll still hit plenty of cases where the resolver doesn't
support those RFCs, and thus we may get behavior such as stripping the
unrecognized EDNS records or maybe even returning an error for the entire
request.  But my prediction is that unknown EDNS records will be much less
likely, compared to unknown question qtype or too many queries, to cause
the really bad behavior where the resolver crashes and behaves poorly for
subsequent "normal" requests.

>
> >
> > Note that none of these ossification issues are really a concern with
> DoH (or DoT) where we can be reasonably sure we're talking to a modern
> non-ossified resolver.
>
> Sorry but I think you have unrealistic hopes, probably caused by largely
> nonexistent auto-disovery of DoH/DoT servers.
>
> AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ!box
> router - mainstream in Germany and countries around) are adding support for
> DoT and possibly also DoH. Personally I do not see any reason why their
> resolver available over DoT/DoH should work any better than their
> unencrypted DNS resolver, which is (at least not in case of AVM) not famous
> for standards-compliance or performance. Of course vendors are going to
> reuse whatever they had before, so additional TLS+HTTP layers will just add
> new bugs on top of whatever bugs they had before.
>
> In other words, whole anti-ossification argument seems to hold at the
> moment only because of missing auto-discovery protocol for encrypted
> transports. Once we have auto-discovery all the problems will bounce back.
> Sorry for my grim predictions!

Yeah, maybe more accurate to say ossification is not an issue for Chrome's
current approach.  Chrome currently only does by-default upgrade for
providers in a hardcoded mapping, and RFC3597 support is an explicit
requirement for the mapping.  For DoT/DoH in general, I would still argue
that ossification is reduced (resolvers need at least one update since the
invention of DoT/DoH and less involved parties when the secure connection
kicks most interceptors out of the mix), but you are correct that it is not
eliminated.

>
>
> > The usefulness of combining queries is a little reduced since DoT and
> DoH often use connection sharing for multiple requests anyway.  But there's
> still some potential value.  In ECH (ESNI) discussions, it has come up a
> few times that an attacker could try to force a downgrade from ECH by
> identifying and blocking the larger packets containing HTTPSSVC responses
> that contain ECH keys but not address resolves.  Much safer if A/AAAA and
> HTTPSSVC can be in the same query/response to force an attacker to block
> everything or nothing.
>
> Hmm, shouldn't it be detected at TLS layer? It seems to me that only
> explotable problem would be if client interpreted connection timeout or TLS
> errors as missing ESNI RR, which does not sound like a good idea to me.
>

Detection might be nothing more than timeout of the HTTPSSVC response.
Specifically because of this attack, the HTTPSSVC draft requires that when
using DoT/DoH, if the HTTPSSVC record results in timeout, transport error,
or SERVFAIL, that the client not fallback to normal behavior using A/AAAA.
Without the attack and RFC guidance, I imagine most clients would respond
to any issues with the HTTPSSVC by reverting to their pre-HTTPSSVC-support
behavior and just using A/AAAA normally because it's not ideal to create
situations where otherwise-working requests could be broken only for the
clients that support the new feature, especially when, at least to begin
with, the vast majority of domains will legitimately not have HTTPSSVC
records.

> Interesting... Do you have measurements which suggest that A/AAAA answers
> have different timing properties? I would expect it mostly depends on
> whatever is in cache, and if multi-query takes off we can expect both to be
> present in cache with the same TTL.
>

I don't have any data on-hand, but the relevant RFC8305 does mention
networks handling some address families sub-optimally as a motivation for
the algorithm.

> > On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Hello.
> >