[dns-privacy] draft-ghedini-dprive-early-data

"Martin Thomson" <mt@lowentropy.net> Wed, 21 August 2019 05:06 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2A38F120853 for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 22:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=QuMXAXQR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xs59Ih0e
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hU4HL1n8zcB0 for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 22:06:34 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16054120071 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 22:06:34 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6681921C0F; Wed, 21 Aug 2019 01:06:33 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Wed, 21 Aug 2019 01:06:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:cc:subject:content-type; s=fm3; bh=wps7wBJh4FTt28zaQjc0ovqwCLP6JkLR9GOgAPufzGg=; b=QuMXA XQRV8oYVoFnzeIoMQRyIWSnZo8hwGistF3vbn4RHPn5frGyjLZYd4xf17UyJ9Bvq vl4IvavRyaHR3PK/I8ET+ZxnYSnHDVPTar037EFFxgiJc3nZ8pMMnpe45b2zLXO8 AY9P5nhBQRUY+ak4cIuB4+70T/YXl3JREuSl+Ii6RyL5a4VMlbEA/ArqjlyTxnM1 5ZDfz8zY3PsYdaiK1Stm/NzJGrDphIXx9o0VylrSCoYqF/gLvhkIMBE+DgkxYeFA h5A2q35NCD/cZk+dhbU+VdfDPJFZ6wBojibVD+XRgobz7L79qCkWpowmRYCUJ2+8 kq9GSqRZVTWoHuhBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=wps7wBJh4FTt28zaQjc0ovqwCLP6J kLR9GOgAPufzGg=; b=xs59Ih0eCLsKdj3IKAk9+1Zi7wUs6GMDSu/AhEX6ilP2i Qwsh3UgJS2bxCzeCOTlBUrh/TorPEYIlSD2kOTdJeIgF0teh3HZf+YglGM2xXu5d /w4Djv10RvbxdD9oM+4rSk8NqBMs6QFnctxRkHWokiWzmw6odesVOjELFimSU4mx yPhiCfpAxj4QQEd8+PgoyL0rFQQd59HJbKUxPUgYAPtzRIu+5EdlaO6SrEgBhaxl w3wRtXOr1/GVZwAnQeJ9AR5EQiWobDP9AERsgudXznPpR5B8MLmNGxDUEZrWRCsD napsvhwWJv5X/gsCHQHLqhVIdYGvL/c5q+hFIf2HQ==
X-ME-Sender: <xms:WdFcXaN3wWCmk5SvFvggOEVI9wwQOCWN-zPCx1A1_29aXPQbUe7IMA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudegvddgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhi nhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd
X-ME-Proxy: <xmx:WdFcXYokmzEwvcRPo-mdS-XGCbv681cgUJW4a9ciRhcqisLX2N8ArA> <xmx:WdFcXc4Qkz9BwhYw4D14xgePXeXvn15GGegor41ZFCHYx_BAxObb2w> <xmx:WdFcXWh_7UuNgZdsc9No2JDa9pjjqeVTTujdKLIntw2Ik-kfAgLm4A> <xmx:WdFcXSncSdOLupjLPvKp6xT9NyWgczPfkf9EvOHOk4F3hhbhxQ_EYQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 07955E00A3; Wed, 21 Aug 2019 01:06:31 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-915-g6cf5a38-fmstable-20190821v4
Mime-Version: 1.0
Message-Id: <a4a6cf19-6ca4-46c2-841b-50f881f7643d@www.fastmail.com>
Date: Wed, 21 Aug 2019 15:06:30 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "Alessandro Ghedini" <alessandro@cloudflare.com>
Cc: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Q53TSXjJl82uigam3XFCCERlYdk>
Subject: [dns-privacy] draft-ghedini-dprive-early-data
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, 21 Aug 2019 05:06:36 -0000

I only just noticed this (don't know why).  I don't know the status of discussion either, so apologies if this isn't appropriate.  The draft is expired, but I felt motivated to comment since I seem to understand the problem a little bit.

TLS early data could be useful for DNS, even if it is less useful given that the cost of connection establishment is amortized quite well in most cases [1].  That assessment might differ depending on your views of the relative merits of endpoints doing their own recursion.

1. This draft could lean more heavily on RFC 8470 and 8446 for detail on TLS early data works and its effects.  The bulk of the intro and even the main section are just reiterations of stuff from there.  Not that that text is bad or wrong, just that it isn't really DNS-specific.  For instance, the ALPN piece probably doesn't need to be repeated.

2. The draft needs to more clearly identify what might be safe to send.  All the draft concretely does is forbid a few things.  If this were just queries, with everything else not allowed unless stated, that might be enough.

3. How does this advice differ for recursive vs. authoritative?  I think that the advice is probably going to be largely applicable to both, but the zone transfer thing seems to be one clear example of a difference worth highlighting.  So you should say "everything except" or - by scoping - concentrate on a use case where there are no differences.  And say that there are no differences.

4. The advice about stateful rotation in 4.1 needs to condition the recommendation on accepting early data.  I'm sure that stateful rotation is fine absent a replay risk.

5. Along the lines of the design in 8470... Is there any signal that might be generated by a recursive resolver toward an authoritative if the recursive is forwarding a query that might have been replayed?  Is there a need for a response indicating that the request should be tried again outside of early data?  I can't see DNS servers holding queries until the handshake completes, so that's unlikely to be a solid recommendation.  Of course, a recursive cannot ensure that the authoritative understands an optional signal in the same way we require reverse proxies to check with origin servers, and a non-optional signal is just going to fail the "can I deploy this" sniff test.  All that to say just that I don't know what the answer is myself, but it sure would be nice if someone could tell me.


[1] RFC 8310 recommends False Start, so maybe my understanding of this space needs enrichment.  But that might be a symptom of a more general problem in that RFC: recommending False Start without qualification isn't a great idea as it exposes clients to downgrade attacks.  It also mandates implementation (or use, I can't tell) of session tickets, which I think is a little off; a more useful mandate would be to insist on clients offering to accept tickets, and then recommend use only when adequate care is taken to avoid the worst of session linkability.  Also (this list is getting long) the implication that "DNS servers on private networks" can't get certificates assumes that public names cannot be used, which is a very different assertion.  But that is all part of maybe considering an update to that document.