IETF Logo Mail Archive

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

Rob Sayre <sayrer@gmail.com> Wed, 08 January 2020 13:13 UTC

Return-Path: <sayrer@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 4A5701202DD; Wed, 8 Jan 2020 05:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wSsCOJTUfxET; Wed, 8 Jan 2020 05:13:01 -0800 (PST)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 E75E41200F7; Wed, 8 Jan 2020 05:13:00 -0800 (PST)
Received: by mail-io1-xd43.google.com with SMTP id t26so3070831ioi.13; Wed, 08 Jan 2020 05:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZTTAbVMkDC6CFSlrxInoai+UdVqVVZfRrdfTfp3zxgY=; b=Rv5ufVKuUMsSfvhsGteaYebOkF6NhmZv1Wz9q8Omc00hZ1rEYj/ZAL5m8wGMzhssPR L6l/G2iuyxRf0YSW8OB2fMAzsqguCc7CBSBGSVFymmGVd4mbZf089Q3HAFBgrwrMUWJM fNAnHV0p3VZgRV54UZdU0/+CkuODieXbkoc3vBEmtnBvS3yWFGPx+1/mUMkzN9CPjNE/ iCBxVW4m3tCAY6moIF00L7GLeawxZ97QQd8v2FPjrzwg8GX52iBZEcZlp8ZoCttnjfkl 2PzyXYMBpPzP2LFhQ1FET5W41jqIen/JNzERi5ppTfQRr+lCwSa/WARHJhvSmeCm+o7n wr1w==
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=ZTTAbVMkDC6CFSlrxInoai+UdVqVVZfRrdfTfp3zxgY=; b=KUa9II8PVg4OuiU6bWgXjVvKSNA+2BClHSYA8ypeWBbNBjkyy19p0oCMAEnbEJR6wE tsy8QfXIrVhNyLGdIrbD6sD8uVaWUHPfjr4BVvrgRBkqff+4Z4zu7qfLcXb6rbFMEmXe eXUqnKZSva0nfwDUyp3YQ6usSDX3K1Qa6oeuuu4NDZKNEu7tlpz6+uLHxoqD89X3mAzB 9eW5UoNh78mpwyVNZmvm8UNcXzANoIdcAcJR8ga6GzTcWxsSwzXV7qhXchzACLPZZRZB unrjQ1Z6g0T6cc5Nfb7WHJW7hcEiJqcTrF9l1HdtyuPZlq3XXyQIsaENw3R/OOBFwFoF aVWg==
X-Gm-Message-State: APjAAAVU+p11MBcsT6vTfIQHZJSBWdaCFkRKXAH8469W1smEbTBlFhGI cyNrdsH1TKqGfmDPdRloxdkJ8b0EHNj+jil3kUS5V8JrQ9PcMw==
X-Google-Smtp-Source: APXvYqz3meJ+JEHUOfWUcFAs9LdIwvQzUz5ys5KDRue+QZTzUoiiLiMRmq6fMn3c+2ILuXbWoxtBBZqzX8TW5kL6bfU=
X-Received: by 2002:a02:ba91:: with SMTP id g17mr4170873jao.106.1578489180139; Wed, 08 Jan 2020 05:13:00 -0800 (PST)
MIME-Version: 1.0
References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <a02720cf-01b3-d61a-94d2-b3d0a399f107@cs.tcd.ie> <20191223220509.GK35479@kduck.mit.edu> <CAChr6SyAhA8V7AQHC67vTEmHWgd+gMzM-ZtFTkBDUhsvVQEC8A@mail.gmail.com> <614B534F-D62D-432C-A3E5-A01D9BF972AA@sinodun.com> <CAChr6SzbtzYPa8D6yFv+f74==6JFQtM+BVyPKR8NAiBG0p-icQ@mail.gmail.com> <98a36517-1a44-3804-6b4c-61be322c8bff@huitema.net>
In-Reply-To: <98a36517-1a44-3804-6b4c-61be322c8bff@huitema.net>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 08 Jan 2020 05:12:48 -0800
Message-ID: <CAChr6Szqf5xj6X6wGkgK5e=doc_4BkxXLykiP5Dqp-KcxceWhw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Sara Dickinson <sara@sinodun.com>, last-call@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, draft-ietf-dprive-rfc7626-bis.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dd3773059ba0a6bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Sagz9lWOBatSCKzlnkuRTI-6idQ>
Subject: Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Wed, 08 Jan 2020 13:13:02 -0000

On Wed, Jan 8, 2020 at 12:00 AM Christian Huitema <huitema@huitema.net>
wrote:

>
> On 1/7/2020 12:08 PM, Rob Sayre wrote:
>
>
> The document contains the text:
>
>   "DoT, for example, would normally contain no client identifiers above
>    the TLS layer and a resolver would see only a stream of DNS query
>    payloads originating within one or more connections from a client IP
>    address.  Whereas if DoH clients commonly include several headers in
>    a DNS message'
>
> Doesn't this just mean "if the DoT client is a good implementation, and
> the DoH client is not..." ?
>
>
> I am not sure that this is just about client identifiers, but there is
> indeed a difference in complexity between DoH and DoT. Yes you could
> minimize it by using an absolutely minimal implementation of HTTP for DoH,
> but the very idea of DoH is to reuse existing HTTP infrastructure for DNS.
> In practice that means a much larger attack surface.
>
I think the concept you're describing is covered by RFC8484, as I wrote.

Is there something in this document's DoH considerations that's new?

thanks,
Rob

v2.23.0 | Report a Bug | By Email