Re: [dns-privacy] Use of 0-RTT in DNS over QUIC

Ben Schwartz <bemasc@google.com> Fri, 30 July 2021 14:53 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52383A2CAD for <dns-privacy@ietfa.amsl.com>; Fri, 30 Jul 2021 07:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.097
X-Spam-Level:
X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T35Ae0bbFSzm for <dns-privacy@ietfa.amsl.com>; Fri, 30 Jul 2021 07:53:16 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10A53A2CA5 for <dprive@ietf.org>; Fri, 30 Jul 2021 07:53:15 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id l4-20020a05600c1d04b02902506f89ad2dso7885804wms.1 for <dprive@ietf.org>; Fri, 30 Jul 2021 07:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LcBFXwTjYcIveNyf87mnMuMZGQk3an5ztXJMddDeYe0=; b=HNA+yH4ydPpDhsUVNmsffh/KX82HROlqueTjL8E701JQm+SEeM6RpEIn4OamFFRR8h nA7aqxkbyPQrlyGYGH0Bwbeg0TfGsV5gxPRkYH/CWk3hgHQtrPQs9ujNfSaFORYgxrJU qT0e4zhXhAtHGRX5rBeKCq5rTYERRz8p+zueB6yMw9OSlGtQoCLEAEoTOWtBmGP9XHgw zLZ/Cpmu3WDaq6zwxVUGLvC6vAgtw0wO/genxL4Dix7XCcGM2KKE/vvSvzUYq6S1ssCP yXl36a2GRAZv7h6UJwyQKbhfrSt8ez2UmzNThv/U6jBwRrJ9jkUnsTSPnyk/cG7oShap 6ADQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LcBFXwTjYcIveNyf87mnMuMZGQk3an5ztXJMddDeYe0=; b=p+ZbBjBcOi5uquVVC7669k4K5YpEsJnqJgi7HvIDM59lbLAeIXObN9t9MZA7ImOmut uhHRAb5GRxkC3Hxcx3tEJSLAJz6WfUp3Qp3CiM81wby9TZwLOxQhJ38GsGk6lRzT2T0M x3tJuOkcEnAcmGwxxfO44x9WBaDRpfn1oCG5Euff/s/JzFsQzAm7pvRQRO+gT8/tIY9G GLv2lN8MS/dExtHFfTjrYjwhXm1E1jRVvborNP0TjXKwFw/0AmLNQKj1yRxtNdv1SWRn mZZQhm6FBRVWP4se4DAOrBTPYjKRGfOjcTRiJoECFMYRuSnRWSLzj4mIIRrVtS7eqmxB g0gA==
X-Gm-Message-State: AOAM5335tnVhz4LHOsJC0Ts934qE7Xjn+x/Ce0uL96tnbjfiJDnlPBMm PJYgFkXtbLWSr5WCWb5eghnZrNkXDCWgN1P1ESWzWcaHxyzKdQ==
X-Google-Smtp-Source: ABdhPJyWmmIU/cqedbJI6olKWCpmM3OvDcDwAbRLRXn7pb2Dhf3QAmY/lRUB2ZpgsId6ze8QreOJxLYgsTGLCd1uEig=
X-Received: by 2002:a1c:9a97:: with SMTP id c145mr3509785wme.42.1627656788936; Fri, 30 Jul 2021 07:53:08 -0700 (PDT)
MIME-Version: 1.0
References: <35e1a3d6-1654-4903-7f1b-77685f59a890@huitema.net>
In-Reply-To: <35e1a3d6-1654-4903-7f1b-77685f59a890@huitema.net>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 30 Jul 2021 10:52:57 -0400
Message-ID: <CAHbrMsB5LEFjfO7o+oLm-i8nccDg9DwnAvFa+pnAUKQvkGfbRA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000c0351e05c8586075"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/e_6idiNB6FERaGCmCd8Z3I-LoTg>
Subject: Re: [dns-privacy] Use of 0-RTT in DNS over QUIC
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 14:53:21 -0000

I think this should be decided as part of
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-early-data, and DoQ
should just reference it.  (I don't necessarily agree with the present
contents of that draft.)

As for what draft-ietf-dprive-early-data should say, I don't have a strong
opinion.  However, I do think it's notable that most recursive resolvers
allow "cache probing" by setting RD=0 in the query, which enables a
relatively straightforward plaintext recovery attack on 0-RTT queries on
multi-instance recursive resolvers.  An attacker can probe a cache instance
until some records of interest fall out, then replay the 0-RTT query and
repeat the probes to see if any of them reappear.  As such, I think it
might be appropriate to strengthen the replay defense requirement for
encrypted DNS beyond the "SHOULD" in RFC 8446.

(See also https://github.com/tlswg/tls13-spec/issues/1225)

On Thu, Jul 29, 2021 at 8:31 PM Christian Huitema <huitema@huitema.net>
wrote:

> The DNS over QUIC draft lets client and server negotiate 0-RTT, with
> minimal guidance. The privacy section develops the risks of replay
> attacks, and then effectively lets clients decide whether to use 0-RTT
> or not. Martin Thomson pointed out the contrast with RFC 8470 which
> provides great details on the use of 0-RTT data in HTTP, and also
> introduces a new error code to let server refuse some transactions if
> received over 0-RTT. There are indeed advantages in letting the server
> control usage of 0-RTT, but I wonder about the proper trade-off between
> control and complexity for DoQ. There are multiple ways to do this:
>
> - Allow servers to not advertise support for 0-RTT if they are concerned
> with 0-RTT side effects -- very simple to implement at servers and clients.
>
> - Let servers advertise support for 0-RTT, but have them check the
> queries received on 0-RTT and return an error code after inspecting
> incoming requests. This requires implementing some kind of filter at the
> server side, plus some logic on the client to resubmit the failed
> requests after completion of the handshake. I am a bit concerned with
> that kind of complexity.
>
> - Let servers advertise support for 0-RTT, but close the transaction
> with a Protocol Error if the server receives an unexpected request --
> e.g., an Update. That also requires some filtering of 0-RTT packets at
> the server side, but is simpler than the full inspection considered
> above. It is also reasonably easy to implement on the client, which
> simply abstains to send some classes of requests over 0-RTT.
>
> - Or, of course, allow servers to support 0-RTT without any kind of
> filtering.
>
> Any particular opinion in the working group?
>
> -- Christian Huitema
>
>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>