[DNSOP] some random dnse-triggered thoughts

Joe Abley <jabley@hopcount.ca> Tue, 04 March 2014 18:38 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4AE781A0262 for <dnsop@ietfa.amsl.com>; Tue, 4 Mar 2014 10:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4DpnBOQ665aF for <dnsop@ietfa.amsl.com>; Tue, 4 Mar 2014 10:38:23 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22B1A02B5 for <dnsop@ietf.org>; Tue, 4 Mar 2014 10:38:22 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id x13so1232861wgg.9 for <dnsop@ietf.org>; Tue, 04 Mar 2014 10:38:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=e1DFiAmS/73Qo7f/4NO4regAshOWAc136mmHlfoE7V8=; b=g1cvWWIpv12qjLeeYHFnl8E6YPnsTVy9h2N4R7yfMzY/6gY2nPtQ1jQ1FdKew61LcJ JF3LsfPH7omlxpChwa/YgMM5M62Iu3yOuTaOxxjBe/n0ZdPDms35gI0i3aMoOBrF0BUw 62MYpT2jDexh0VZpH10zdmn6skcZQslAaml1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=e1DFiAmS/73Qo7f/4NO4regAshOWAc136mmHlfoE7V8=; b=RLaYs+kkDeXhn6eALlPxhZl6nLzndEbjXYkSLAIpeb9AqJebTmJAQYmYRDJDEEXbHI U0RfAMHe6nNX6iVR95TGXA/fbvl3dWhRn/CcxGUybQ11ujcJQPVD3WWP1f8Uku9LoTs8 9KWdkw5dXcsvJxBNtYm+dOyQOeabuTmuIhKwAHWU9wcdYGr0Y6WWv19G735KSg26W9CA zr8UYay8EiAMc58tnh01vCRNYOWhFtEDaxZRZAqhjuk6gPSGS1OS/ALEnV/0DtxftBdY h3M878jRn59Zlk4PAd3yaPipHKM7sYGytp3XefL5L9MshgbcZ9Y7ZTMOmEAVPkdyQW2T vcRg==
X-Gm-Message-State: ALoCoQkLcTXuR/sEyIevMbWmN5wOWHQroFnX+bOaX/d5RfDkTfOrPkKBn9z61TbtP23OMeYzGM6m
X-Received: by with SMTP id wu8mr1212587wjb.91.1393956939970; Tue, 04 Mar 2014 10:15:39 -0800 (PST)
Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:5035:8e67:4065:e5fc]) by mx.google.com with ESMTPSA id r3sm55543060wjw.0.2014. for <dnsop@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 10:15:39 -0800 (PST)
From: Joe Abley <jabley@hopcount.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <B63680DF-C56B-4AEB-9F76-A01FA2625D32@hopcount.ca>
Date: Tue, 4 Mar 2014 18:15:37 +0000
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/VX9obZ6mpMAWOz_weXUf55266hU
Subject: [DNSOP] some random dnse-triggered thoughts
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 18:38:25 -0000

I have not reviewed all these drafts thoroughly, since I am a slacker, and so what follows is mainly a reaction to presentations and not a detailed reading of the text. So, in no particular order (hence numbering):

8. draft-hzhwm-start-tls-for-dns-00, TO not protected

It seems like a potential problem that the TO bit is not protected. A middlebox could strip TO in one or both directions and prevent TLS from ever being established. To both ends of the transaction, this seems indistinguishable from the case where the other end just doesn't support TO. A secure assertion around TO seems necessary. See 3b(ii).

3. draft-hzhwm-start-tls-for-dns-00, address to name mapping not 1:1

It seems like the nameserver name needs to correspond to some data in a certificate in order to confirm that the certificate being presented by the other end is authentic. It's possible in the DNS for many nameserver names (NS RDATA) to correspond to the same physical server. How does a server receiving a query know which certificate to present?

7. draft-hzhwm-start-tls-for-dns-00, not specified for UDP

I am personally a fan of investigating ways in which opportunistically-persistent pools of TCP connections between DNS clients and servers could be used as an alternative to today's UDP spray, which as we know has a habit of bouncing off the urinal wall and making a mess of other peoples' shoes. I think we are some distance from understanding the operational implications of this, however, and it seems like a shame to gate this privacy proposal on that problem being solved. Pretty sure Duane called this out already, but I mention it again if for no other reason than to subject everybody to a toilet metaphor.

4. draft-wijngaards-dnsop-confidentialdns-00, let's use EDNS0

It solved some (not all) response size concerns for DNSSEC to have the DO bit specified in the EDNS0 header, since you then can't ask for a secure response without supporting EDNS0 and hence larger buffer sizes. Encrypted data (with padding) is also going to lead to larger responses; the same benefits might apply.

17. draft-wijngaards-dnsop-confidentialdns-00, architectural considerations

In the past when there was a desire to change the message format semantics, the OPT pseudo-RR was specified. If we consider this an established architectural approach, then we might consider that this proposal is also changing message format semantics; perhaps encryption of the various sections in the DNS message could be signalled through a similar pseudo-RR as an alternative to hiding encrypted data within a standard-format RRType (which seems a bit ugly). Perhaps it's worth re-casting this proposal as an EDNS0 option, or even as an EDNS1.

EDNS0 options are hop-by-hop. It's not obvious this is what we need, since that makes every intermediate DNS server a potential interception point. But perhaps that's ok anyway, if we imagine the 80% solution involves stub -> resolver -> authority where each arrow is a separate privacy domain anyway.

3b(ii). draft-wijngaards-dnsop-confidentialdns-00, ability to assert capabilities using DNSSEC

The ability of a zone manager to assert the capabilities of the authoritative servers for that zone, and sign that assertion with DNSSEC, seems like a strength of this proposal in the sense that a client can gain confidence in the availability of a secure channel to an authoritative server, and can plausibly reject responses that suggest that the server is not capable for fear that they have been injected by an intermediary.