Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

[Eric Orth <[e-mail]>]

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

>
>
> 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.
>

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.


>
>
> > 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.
>
> 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.


>
>
> > *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 <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     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
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>