Re: [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08
Allison Mankin <allison.mankin@gmail.com> Thu, 27 January 2022 13:37 UTC
Return-Path: <allison.mankin@gmail.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 BD3B83A08B0; Thu, 27 Jan 2022 05:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T4IjqnxunaDs; Thu, 27 Jan 2022 05:36:56 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 B7DC33A08AD; Thu, 27 Jan 2022 05:36:55 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id m4so5832427ejb.9; Thu, 27 Jan 2022 05:36:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2rTYEBzFmT8LLjGvtZbS5rXqJzOuNEHqEPKMZfB81Bo=; b=qWIrPGO6ymCl2tCldAQQX5TTFU27NgDxNcofWKEOHXVdRKasnqD4t6P/E3cbyMXcw/ uh7XltOZPv9XkmFvLYvweUC8B2kdonAVngOz9KbHg+JAaq0cGUBzQbkhmCzg/aRQQl1o Z+EsUpLqfyOfCMExLFq1tQz2oflXdKeW9vLHppz9G5kUNxAY0boHPda206A+3mbm3W9d /14D6k48crpGWR1Ozl/ChJBQW+6vRi0Kyklv6AU35/rzH7GnJ1iEd4cDAVILWUBauLa8 VeR/U0pqJYgbmJHlqzlg4gMGJeir60RbQQPIw7zIUtbFCnkChYEfpaFmehyvDqPszlO+ p+pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2rTYEBzFmT8LLjGvtZbS5rXqJzOuNEHqEPKMZfB81Bo=; b=Co0q0Zlr29oY6s39Q3OrNLeJrhr+oRKJN4VzadDJnKNXmvyCDq3QfGzaPBsaJUtwUp JjsXIJm9/XRJtFSVwsPg6KgXNrPtl2IMtNbvSoe7aLbmutsM+PrSuIXQBiHnN/LVDPo1 DnNYwgTeV12kFkBqzWSxzg4NzgqtKbybtKtsOPg5mckym8HYQ9K91a4kev3VBAEL/13A 8IwMl7eCQsw/psTkMnQE3RIePcUlRAe9C3RDHnZ4VwuOb1TddQSaZ8lCj188gWoCyx5S N2iUj4xwt6JmWz51+UbMlkCD+17tpq5fSXyNQTZf6wDPOKqX4SfEiHPmRajxYsUanHY7 xfFw==
X-Gm-Message-State: AOAM532jE6qpTgtxziJGx4wGyDd0vKmGL1kjR7LZstAuhsS/WuyiWiZF 1osQiK630YznqaQSLYrnjw8IWqVvZP8D2NRttP5l0YT2
X-Google-Smtp-Source: ABdhPJyfsA6SRAQldkdSeATs6FV9iKoI1l2ECSgMfDTHhiFIFJF2RHj5NNGJrriBlOc2O27cX22NZcmvIhPkMaoZclo=
X-Received: by 2002:a17:907:3f97:: with SMTP id hr23mr2938956ejc.578.1643290613081; Thu, 27 Jan 2022 05:36:53 -0800 (PST)
MIME-Version: 1.0
References: <164303671825.29006.13435316265266313857@ietfa.amsl.com> <e81b7117-126a-4557-b020-eb5dbffa775b@huitema.net> <E131CF24-A64B-481A-A856-11B83886B154@sinodun.com>
In-Reply-To: <E131CF24-A64B-481A-A856-11B83886B154@sinodun.com>
From: Allison Mankin <allison.mankin@gmail.com>
Date: Thu, 27 Jan 2022 08:36:42 -0500
Message-ID: <CAP8yD=sTW0JYF9bApshJ6RFoYYVRbOQGsQs9DWwVCiyFPU7+fQ@mail.gmail.com>
To: Sara Dickinson <sara@sinodun.com>
Cc: Brian Trammell <ietf@trammell.ch>, Christian Huitema <huitema@huitema.net>, DNS Privacy Working Group <dns-privacy@ietf.org>, draft-ietf-dprive-dnsoquic.all@ietf.org, last-call@ietf.org, tsv-art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000416ac705d6906959"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ycckeky3B4OPogcROgRkcOSgdPQ>
Subject: Re: [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08
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: Thu, 27 Jan 2022 13:37:01 -0000
I share Sara's position. On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <sara@sinodun.com> wrote: > Hi Brian, > > Thanks for the review, and as Christian said the padding question has been > a point of discussion. > > I’m personally comfortable with a downref to RFC 8467 with text to support > why this is done as you suggest. Multiple studies have shown just how easy > traffic analysis is without any padding - we could actually cite one of the > more recent ones. RFC 8467 is implemented for stub-recursive DoT in most > open source software and is in use by major recursive operators. For me > this approach mitigates the immediate risk of exposing DNS names - > preventing traffic analysis from identifying DoQ is a much longer term goal > (and requires ECH). > > I’ve had a first pass at a PR making RFC8467 normative here: > https://github.com/huitema/dnsoquic/pull/143 > > Regards > > Sara > > > > On 26 Jan 2022, at 20:32, Christian Huitema <huitema@huitema.net> wrote: > > > > Thanks for the review, Brian. > > > > We have been going back and forth on the padding requirements, and the > current text is specifically written to avoid a downward reference to RFC > 8467. You are making a good arguments that it is hard for implementers to > comply with a requirement that they MUST pad if there is no specific > guidance about how to pad. On the other hand, I think that we should not > delay publication until getting definitive agreement on the appropriate > padding policy. For example, we would have to resolve the tension between > application specific padding, with a goal to hide which DNS names are being > queried, and generic transport level padding, with a goal to prevent > traffic analysis from distinguishing between DoQ and other applications. > So, I am inclined to just replace MUST by SHOULD, and leave it at that. > That's one of your proposed remedies, but I wonder whether others might > object. > > > > -- Christian Huitema > > > > > > On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote: > >> Reviewer: Brian Trammell > >> Review result: Ready with Nits > >> > >> This document has been reviewed as part of the transport area review > team's > >> ongoing effort to review key IETF documents. These comments were written > >> primarily for the transport area directors, but are copied to the > document's > >> authors and WG to allow them to address any issues raised and also to > the IETF > >> discussion list for information. > >> > >> When done at the time of IETF Last Call, the authors should consider > this > >> review as part of the last-call comments they receive. Please always CC > >> tsv-art@ietf.org if you reply to or forward this review. > >> > >> This document is a mature and straightforward mapping of DNS over QUIC, > >> modeling a QUIC connection as equivalent to DNS over TCP with one query > >> per stream. 0-RTT and fallback design choices are reasonable and > >> well-explained. Security and privacy considerations are well-presented. > >> All in all, a very good example of an application mapping over QUIC. > >> > >> I have only a few nits here: > >> > >> Editorial nits: > >> > >> - in section 5.3.1, is STOP_SENDING spelled "STOP_SENDING" > >> or "Stop Sending"? Please choose one. > >> > >> - "These privacy issues are detailed in Section 9.2 and Section 9.1" > >> is a weird order; please swap. > >> > >> Content nit: > >> > >> I understand the intent behind "Implementations MUST protect against the > >> traffic analysis attacks described in Section 9.5 by the judicious > injection of > >> padding"; however (1) there is no interoperability risk from failing to > comply > >> with this restriction, and (2) as an implementor, it would not be clear > to me > >> how to prove my padding injection was "judicious". > >> > >> There is a reference to an experimental RFC 8467 that presumably defines > >> acceptable padding policies, but it is referenced as "should consider". > >> > >> I would recommend one of the three following remedies: > >> > >> - change this to a SHOULD (since verifying compliance is impossible as > phrased), > >> - add a normative downref to 8467 and make it clear that that reference > defines > >> padding policies considered compliant, or > >> - provide some other guidance implementors can use do determine whether > >> they are padding enough to be considered compliant. > >> > >> Further, traffic analysis threats are not limited to packet lengths, as > section 9.5 > >> acknowledges. Is there any equivalent MUST guidance regarding stream > frame > >> timing for traffic analysis resistance that could be given here? > >> > >> > >> _______________________________________________ > >> dns-privacy mailing list > >> dns-privacy@ietf.org > >> https://www.ietf.org/mailman/listinfo/dns-privacy > >
- [dns-privacy] Tsvart last call review of draft-ie… Brian Trammell via Datatracker
- Re: [dns-privacy] Tsvart last call review of draf… Christian Huitema
- Re: [dns-privacy] Tsvart last call review of draf… Sara Dickinson
- Re: [dns-privacy] Tsvart last call review of draf… Allison Mankin
- Re: [dns-privacy] Tsvart last call review of draf… Brian Haberman
- Re: [dns-privacy] Tsvart last call review of draf… Daniel Kahn Gillmor
- Re: [dns-privacy] [Tsv-art] Tsvart last call revi… Brian Trammell (IETF)
- Re: [dns-privacy] [Tsv-art] Tsvart last call revi… Allison Mankin
- Re: [dns-privacy] [Tsv-art] Tsvart last call revi… Sara Dickinson